Omit late bound privates from declaration emit if their name is inaccessable

[weswigham]

This may only be considered always safe enough to do if the private is a unique symbol; then again this is likely fine for all late bound names (as implemented) as prior to adding late bound name support we would have elided them anyway.

Fixes #20080

[mhegazy]

we want to keep the private in the type.. why remove late-bound names?

[weswigham]

If the name is impossible to posses outside of the local scope, then it is impossible to conflict with, ergo retaining the private holds no value.

[weswigham]

Plus, computed names like these were elided pre-dynamic-names anyway, so this is a conservative behavior.

[mhegazy]

We do not know that.. you can have a function that returns you the same symbol.. the symbol can "escape" in multiple ways..

[weswigham]

In value-space, yes, the name can escape (all you'd need to do is alias the type or something); but it can't as far as our type system in concerned - if the late bound name is exported then we'll write the private, since it is visible and we know the name can be referenced elsewhere, if it is not visible, then there's no public way to access the same name, ergo you can't conflict with it (or at least we have no way of checking).
For instance:

const _data = Symbol('data');

export function getDataSymbol() {
  return _data;
}

export class User {
    private [_data] : any;
};

getDataSymbol returns symbol (not a reference to _data's unique symbol), even though it's easy to see that you could make a subclass that attempts to mangle the same symbol, we have no way of verifying that it is, in fact, the same symbol (since it didn't come from the same origin).

[weswigham]

And if you annotate getDataSymbol to explicitly return typeof _data, we'll happily tell you at that point in time that _data isn't exported and cannot be named (and once it is exported we'll write the private member out).

[rbuckton]

The problem is this case (simplified):

// a.ts
export const x = Symbol();
export function getX(): typeof x { return x; }

// b.ts
import { getX } from "./a";

const x = getX();

export class C {
  private [x]: number = 1;
}

// c.ts
import { getX } from "./a";
import { C } from "./b";

const x = getX();

export class D extends C {
  private [x]: string = "a"; // oops
}

[weswigham]

Hmm... I suppose the correct thing to check isn't visibility from the current declaration, but rather if the the name is reachable via the exports of its containing file at all. And then adding a visibility check to ensure an alias to it is visible in scope and complaining that it cannot be referenced if not. Meaning

import { getX } from "./a";
import { C } from "./b";

const x = getX();

export class D extends C {
  private [x]: string = "a"; // oops
}

is an error because x cannot be named in the declaration file (without modifying its shape, anyway), while

import { getX, x as xsym } from "./a";
import { C } from "./b";

const x = getX();

export class D extends C {
  private [x]: string = "a"; // oops
}

is fine since the name can be written by its alias from a.

[mhegazy]

so why not just keep the private, and the const with the unique symbol, but just add a export {}; to the file to make the scoping work correctly.. we talked about this before in the context of other declaration emit issues.

[dpogue]

Any chance of this getting in to the 2.7 release?

[weswigham]

As is this fix is a bit incomplete, so it's not scheduled for the initial 2.7 release right now.