@falsandtru对于这些问题，你必须具体说明预期行为是什么，以及当前的实际行为是什么。你能详细说明一下吗？

抱歉，我更新了描述。

所以我们在noImplicitAny上没有出错的原因是因为你在一个环境上下文中。类中的私有成员被描述为any是因为这样做的目的是隐藏实现细节，如果你查看我们生成的.d.ts文件，你会发现我们使用any作为私有声明的属性。

我知道你的想法。类中的私有示例成员不可访问。

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

但私有静态成员不是。

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

这种可访问性似乎不是设计的意图，因为私有静态成员的这种可访问性逃避了私有成员（例如）的不可访问性。ImplicitAny类型在实现中是可见的。实际上，a和b变量具有implicitAny类型。这些implicitAny类型应该是错误的。这真的是允许的、预期的可访问性吗？

这是一个很好的观点@falsandtru。我不认为我们以前想到过这一点。现在启用对这些声明的非隐式检查将是一个突破性的改变。鉴于这种模式并不常见，我想知道是否值得。

TypeScript类型的系统策略是一种平衡，但非隐式的任何检查可能不是。它的检查是完美的。我认为下一个主要版本到2.0是一个很好的机会进行突破性的变化。如果这种模式不像你说的那样常见，这个突破性的变化是很容易的。TypeScript可以很容易地得到更正确的非隐式的任何检查。

鉴于这种模式并不常见，
我指的是使用静态属性作为typeof表达式的目标来输入其他内容。私有静态属性是一种常见的模式，如果将其作为一个错误，则会破坏很多代码。例如，编译器生成的所有.d.ts文件都将无法通过此检查。

我们希望非private属性使用私有属性typeof时出现错误。