使用 Closure Compiler，Array<T> 注释与仅 Array 相比有什么好处？

Question

我希望 Closure Compiler 会在下面的所有行上发出警告，但只有 3) 显示为问题。 Type Checking Array Contents with Closure-Compiler 涉及到这一点，但我的问题是，鉴于这些限制，注释 Array<T> 与 Array 有什么好处？我觉得这是一种虚假的安全感。

// ==ClosureCompiler==
// @compilation_level SIMPLE_OPTIMIZATIONS
// @output_file_name default.js
// @warning_level VERBOSE
// ==/ClosureCompiler==

/** @type {!Array<!string>} */
var xs = [];
xs.push(42);       // 1) no warning
xs.push(null);     // 2) no warning
xs = 'foo'         // 3) warns - found: string, required: Array<string>
xs = [1,2,3];      // 4) no warning

快速编辑：您可以在http://closure-compiler.appspot.com/ 使用此代码

Answer 1

我怀疑这是因为externs definition for Array.prototype.push 不太正确。如果您删除 @this 类型，那么您应该得到预期的错误。不过，可能是由于某种原因添加了 {length: number} 部分，因此删除它可能会在某处破坏某些现有代码。

Answer 2

您将获得与其他静态语言一样的泛型优势。
假设您要创建一个字符串数组，然后使用它们的长度对它们进行排序。

var arr = [];    
arr.sort(function(a, b) { return a.length - b.length; });

如果您将数组注释为Array，那么您将能够向数组添加一个数字，并且闭包编译器不会抱怨。
最终你会遇到一个异常，因为数字没有长度属性。
如果您将数组注释为字符串数组Array<string>，那么您将确保长度属性存在并且没有人能够插入除字符串之外的任何其他类型。

我不明白为什么你用字符串没有编译错误，但如果你用数字试试，你会得到不同的编译结果。

// ==ClosureCompiler==
// @compilation_level SIMPLE_OPTIMIZATIONS
// @output_file_name default.js
// @warning_level VERBOSE
// ==/ClosureCompiler==

/** @type {!Array<!number>} */
var xs = [];
xs.push(42);
console.log(xs[0].length);

=> 
Number of warnings: 1

JSC_INEXISTENT_PROPERTY: Property length never defined on Number at line 4 character 18
console.log(xs[0].length);
              ^