Leak of `noImplicitAny` checking with private static property

[falsandtru]

declare class C {
  private static implicitAnyTypeProperty;
  static inherited: typeof C.implicitAnyTypeProperty;
  inherited: typeof C.implicitAnyTypeProperty;
}

expected:

$ node_modules/.bin/tsc index --noImplicitAny
index.ts(2,3): error TS7008: Member 'implicitAnyTypeProperty' implicitly has an 'any' type.

actual:

$ node_modules/.bin/tsc index --noImplicitAny

[DanielRosenwasser]

@falsandtru with these issues you'll have to be specific about what the expected behavior is and what the current actual behavior is. Can you elaborate on that?

[falsandtru]

Sorry, I updated the description.

[DanielRosenwasser]

So the reason we don't error on here with noImplicitAny is because in you're in an ambient context. Private members in classes are intended to be described as any because the idea is to hide implementation details, and if you check out our generated .d.ts files, you'll see that they we use any for private-declared properties.

[falsandtru]

I know your idea. Private instance members in classes have inaccessibility.

declare class C {
  private implicitAnyTypeProperty; // not an error because this type is inaccessible
}

but private static members are not.

declare class C {
  private static implicitAnyTypeProperty;
  static inherited: typeof C.implicitAnyTypeProperty;
  inherited: typeof C.implicitAnyTypeProperty;
}
var D: typeof C;
//class D extends C { }
var a = D.inherited; // should be an error because this variable accessed to implicitAny type
var b = new D().inherited; // same as above

This accessibility seems not intended design because this accessibility of private static members escapes inaccessibility of private members (for instance). ImplicitAny type is visible from implementations. Indeed, a and b variables have implicitAny type. These implicitAny type should be an error. Is this really allowed, intended accessibility?

[mhegazy]

This is a good point @falsandtru. I do not think we thought of that before. enabling no-implicit-any checks on these declarations would be a breaking change now. Given that this pattern is not common, I wounder if it is worth it though.

[falsandtru]

The TypeScript type system policy is a balance, but no-implicit-any checks is probably not. It checks is desired to be perfect. I think that the next major version up to 2.0 is a good chance for breaking changes. If this pattern is not common as you say, this breaking change is easy. TypeScript can get more correct no-implicit-any checks easily.

[mhegazy]

Given that this pattern is not common,

i meant the use of a static property as a target of a typeof expression to type something else. The private static property is a common pattern, and making this an error would break a lot of code. for instance all the .d.ts files that were generated by the compiler would fail this check.