Use for .. in to iterate over arrays. NFC

[sbc100]

This seems to save some code size.. are there any downsides?

[sbc100]

Of course once we get to https://github.com/emscripten-core/emscripten/issues/11984 we can use const and for .. of.. but this seems like a reasonable intermediate step.

[RReverser]

This at least used to have worse performance in modern engines than a C-style for loop for arrays, since it has to check any properties and not just integer indices.

Personally, I'd probably keep the old version. It might be useful to see how much this saves on practice (after gzip/brotli) on some real-world example, but I doubt it's much.

[sbc100]

OK sounds good. I'll close this for now.

Would using for .. of .. help once we have ES6 by default?

[juj]

for ... in iterates over the array differently compared to the C style for loop. The difference happens when the prototype of Array is modified:

I used to be a big fan of for ... in, but people kept raising bug reports about different frameworks expanding Array.prototype for new functionality, which would break compatibility with for ... in.

So to be safe, we should never use for ... in to iterate over arrays, since we don't know what kind of environment the code will be executing in. (I could entertain a -s UNMODIFIED_ARRAY_PROTOTYPE=0/1 option, but I already can hear how people will hate the idea :D )

for ... of does not have the above problem (it won't print asdf). I think it would be good to have an internal preprocessor flag to allow using ES6 constructs. The spread syntax ... is another one that will give a nice code size saving as well.

Although yeah it's good to note that both for ... of and ... spread syntax do have a microbenchmark history of being worse in performance. Though this would only matter in WebGL library maybe, all other places are generally very perf agnostic.

[RReverser]

I think it would be good to have an internal preprocessor flag to allow using ES6 constructs. The spread syntax ... is another one that will give a nice code size saving as well.

I agree, same for various class constructs and object shorthands - we certainly have a bunch of places where those could help.

[RReverser]

Maybe we could enable those as part of the new ESM mode discussed in issue about ES6 exports. I think it would be reasonable to tie the two together.

[sbc100]

Maybe we could enable those as part of the new ESM mode discussed in issue about ES6 exports. I think it would be reasonable to tie the two together.

I have a plan for how to enable ES6 across the codebase: #11984 . Basically I hope to enable ES6 by default and then force transpilation when users opt into older browser support. One key pointer is that we would like the default settings not to require transpilation which means the default broswer support settings need to have ES6 support (which I suspect they already do).

[RReverser]

Thanks, the plan in that issue looks solid, and I like the idea of just assuming that Wasm-supporting browsers have ES6 anyway. Btw, the stale bot just marked that issue as stale, you might want to bump it up (or resolve 😛).