Typed arrays not shimmed when using ECMASCRIPT3

[cmacordex]

Since Uint8Array and its friends are not part of the ECMASCRIPT3 spec, I assumed that they would be shimmed for compatibility when using --language_out=ECMASCRIPT3. E.g., something like this:

var a = new Uint8Array([1, 2]);

=>

var a = window.Uint8Array ? new Uint8Array([1, 2]) : [1, 2];

And likewise, although IE 10+ supports some Uint8Array methods, it doesn't support all of them, like slice:

a.slice ? a.slice() : Array.prototype.slice.call(a);

Using ECMASCRIPT3 as the language_out, no transformation is performed. E.g. running this:

java -jar compiler.jar --compilation_level ADVANCED_OPTIMIZATIONS --new_type_inf --warning_level VERBOSE --language_in ECMASCRIPT_NEXT --language_out ECMASCRIPT3 \
    --output_wrapper ";(function() {%output%}());" --js test.js --js_output_file=test.min.js --module_resolution NODE

on this:

var a = new Uint8Array([1, 2]);
console.log(a[0]);
console.log(a.slice(1));

produces this:

;(function() {var a=new Uint8Array([1,2]);console.log(a[0]);console.log(a.slice(1));}());

Since typed arrays are part of the language definition, shouldn't ECMASCRIPT3 shim them? Also, is there any other configuration I should be changing?

Link to appspot test: https://closure-compiler.appspot.com/home#code%3D%252F%252F%2520%253D%253DClosureCompiler%253D%253D%250A%252F%252F%2520%2540compilation_level%2520ADVANCED_OPTIMIZATIONS%250A%252F%252F%2520%2540output_file_name%2520default.js%250A%252F%252F%2520%2540language_out%2520ECMASCRIPT3%250A%252F%252F%2520%253D%253D%252FClosureCompiler%253D%253D%250A%250A%252F%252F%2520ADD%2520YOUR%2520CODE%2520HERE%250A%250Avar%2520u%2520%253D%2520new%2520Uint8Array(%255B1%252C%25202%255D)%253B%250Avar%2520v%2520%253D%2520u.slice()%253B%250Aalert(v%255B0%255D)%253B

(Also, as always, thanks for all your work on Closure Compiler - it's made JS development much better for me.)

[blickly]

To be honest, I'm not totally sure what the metric is for determining which features we should be in the business of polyfilling. Originally, I thought we only polyfilled ES6 features, but I think that may be no longer the case.

@brad4d, do you know if we have a concrete policy on this?

[cmacordex]

I believe typed arrays are part of ES6: https://www.ecma-international.org/ecma-262/6.0/#sec-typedarray-objects

[concavelenz]

This is a grey area. TypedArrays, like Promise, supercede ES6 but they are not part of ES5. I'm a little wary of adding them at this point because we have gone without them for so long and I expect there is a fair bit of code that changes behavior when TypedArrays are detected that we might either break or regress by polyfilling. We only added Promise because it was required for async functions and there we did break some feature detection code.

Is there an existing polyfill you could use, without the compiler adding it?

[cmacordex]

@concavelenz I ended up polyfilling it myself from a combination of sources. I agree with your point about introducing them breaking feature detection code.

Perhaps they could be added under a flag like --polyfill-all or something. But I understand that would be very low priority.

Thanks again for all your hard work on this project.