Private member access and type information inconsistency.

[Steve-Fenton]

In section 8.2.2 Accessibility private members are not accessible outside of the class they are declared in.

However, you can access them using their key and when you do so, the type information is even inferred.

Here is the example:

class Example {
    private private: number;
    public public: number;

    constructor() {
        this.private = 1
    }
}

var example = new Example()

var a = example.private; // Error
var b = example["private"]; // number
var c = example["other"]; // any 
var d = example["public"]; // number

a) Expected behaviour (error)
b) Should be error. If the compiler knows enough to say "it's a number", can it not also say "it is private"?
c) Expected behaviour (any)
d) Expected behaviour (number)

So in the case of variable b, should the private member not cause a compile-time warning?

[ghost]

We have been discussing this on SO

From what I know about TypeScript, it is meant to support normal JavaScript as correct syntax. This would mean that this specific example of accessing a private member by the object map should always be allowed. However, if --noImplicitAny exists, then we should also have a --strictTypes or something that forces all compiled code to use types and obey the rules.

[danquirk]

I can see how this feels weird. At the same time string indexing is generally an escape hatch for a variety of things. Likewise private isn't truly private and it feels a little weird to disallow this under noImplicitAny. Even if this example is fixed you still get the same behavior when a variable is used with the value 'private' rather than the direct literal value. Maybe this could be a rule in #274 but in general I suspect few people run into this issue. Maybe it becomes more valuable if we ever were to start tracking literal values flowing through variables.

[Steve-Fenton]

Hi Dan,

I think that is a fair assessment. If the type of the property was any this would be more consistent as it would behave the same for all of the following:

var a = example[myStringKey]; // any
var b = example["private"]; // any****** (currently infers number)
var c = example["other"]; // any 

It just seems strange to go as far as tracking that "private" is of type number, when unknown or untracked strings wouldn't do this (especially as it is supposed to be private - but I understand why you wouldn't want to enforce that).

[mhegazy]

Looks like there is no more information needed here. closing.