When working with Google Closure, there is a question about initializing an Array of a specific @type{Array.<type>} and whether or not Google Closure will confirm the Array contents.
A test case has revealed that an {Array.<string>} seems to pass through an {Array.<number>} check, while a {string} is correctly blocked by the same check. Is this possibly an error on the part of someone new to GC?
This issue was tested using the Google Closure Service, resulting in only one expected error on September 12, 2013. Additional testing was performed on a local jar file (version v20130823) with ADVANCED_OPTIMIZATIONS and warning_level VERBOSE. The problem persists with the {Array.<string>} passing through the check.
For more information, refer to the documentation: Annotating for Google Closure
Your input on this matter would be greatly appreciated.
// ==ClosureCompiler==
// @output_file_name default.js
// @compilation_level ADVANCED_OPTIMIZATIONS
// @warning_level VERBOSE
// @language ECMASCRIPT5
// ==/ClosureCompiler==
/**
Expected behavior - no warning:
@type {Array.<number>}
*/
var a = [1,2,3,4];
/**
Warning! Type mismatch as expected:
@type {Array.<number>}
*/
var b = 'mismatch'; // {string} does not match {Array.<number>}
/**
Unexpectedly no warning for type mismatch:
@type {Array.<number>}
*/
var c = ['foo','bar']; // {Array.<string>} should not match {Array.<number>}
// prevent compile-to-zero
alert(a);
alert(b);
alert(c);
Note: Similar issues have been discussed in this related question, specifically regarding manually filling in the type of Array.push(). This current concern, however, focuses on initialization. Even after implementing suggested corrections and populating arrays with irrelevant data, it seems that Google Closure fails to detect discrepancies in type matching.
Edit: Additional measures were taken by including warning_level VERBOSE and language ECMASCRIPT5 in the header of the test case. Despite these efforts, the issue of {Array.<string>} evasion remains unresolved.