Useless feature

[aquapi]

• As this is relying on the iterator protocol, it will be significantly slower than a simple for loop. JavaScript is only 2x - 4x slower than some compiled language for a reason.
• Since JavaScript is already bloated, we don't need another feature that can be done using a two liner. New JavaScript should improve performance or do something that was impossible to do in JS before.

[tabatkins]

Thank you for your feedback. We disagree, and believe there is significant value in providing built-in functions for common, non-trivial operations. Offering fundamentally new behavior is very useful, but making common patterns easy to write (and, by being built-in, easy to recognize and reason about in others' code) is also valuable.

[phoddie]

(I don't have a position on this proposal.) I was surprised that this feedback elicited such a strong, swift response:

New JavaScript should improve performance or do something that was impossible to do in JS before

This appears reasonably consistent with the Extensible Web Manifesto which states, in part:

• Focus on adding new low-level capabilities to the web platform that are secure and efficient
• Free up the standards process ... to focus on features with security or performance concerns, and features that can only be added at the platform level...
• Develop, describe and test new high-level features in JavaScript, and allow web developers to iterate on them before they become standardized

@tabatkins, you support (or once supported) the manifesto. Thoughts?

[ljharb]

That point on the manifesto isn't exclusive of the third one:

Develop, describe and test new high-level features in JavaScript, and allow web developers to iterate on them before they become standardized. This creates a virtuous cycle between standards and developers.

This proposal would fall into that bullet.

[tabatkins]

You're misreading the EWM. ^_^ In the very text you're quoting, it's saying "allow web developers to iterate on them before they become standardized" - the entire point is to standardize convenience features when they're proven to be useful. Ranges have a long history across multiple languages of usefulness.

[tabatkins]

(I'll note that this misreading of EWM to mean "only ever define low-level primitives that unlock something new" is unfortunately common, and implies we should have written the EWM a little more explicitly in this regard. The problem the EWM was intending to aim at was the practice of defining high-level features that added new functionality without the ability to use that new functionality except exactly as the high-level feature expected it to be used. If your use-case was a little off from what the feature addressed, too bad, you were SOL. Providing reasonable access to primitives and composed, convenient APIs built on those primitives is the best of both worlds.)

[tabatkins]

Also, this thread in particular (and the similar one opened by the same person shortly after I closed this one) are violations of our Code of Conduct - language like "Useless feature" and a combative tone are not conducive to people feeling welcome, safe, and productive. Closing with a simple answer was an attempt to avoid further escalation.

[phoddie]

Complete agreement: the tone of the initial post on this issue is beneath TC39. You were right to close it.

Thank you for the explanation of the EWM. Fortunately there's no misreading of the EWM here. I understood what you explained when selecting those excerpts.

While it was the wrong way to open a discussion, tradeoffs between convenience and performance are a valid concern. Developers eager to adopt a convenient new API may be unpleasantly surprised to discover they underperform their less convenient predecessors. That has happened. And, the risk of that is higher on devices where performance is lower, which is why this resonates with me.

[kmiller68]

I completely agree with the performance concerns with the iterator protocol. It's unfortunate that the protocol requires allocating an object on each iteration of the loop. I wish ES2015 used a special flag e.g. Symbol.iteratorDone to signal a loop was finished. While it's possible for engines to optimize away the allocation for native iterators, it's a herculean task to get right. That said, at least as far as this proposal is concerned, I think the iterator protocol ship has sailed.

[bakkot]

I completely agree with the performance concerns with the iterator protocol. It's unfortunate that the protocol requires allocating an object on each iteration of the loop.

Ehh... it's not all that hard to write an implementation which avoids the allocation for built-in iterators, including generators. A while ago I wrote up a doc on doing it in V8 but it probably generalizes. Optimizing away the allocation in general is hard but writing an implementation which avoids the allocation in built-in uses of the iterator protocol consuming built-in iterators shouldn't be that hard.

(I've recently been doing some editorial work in 262 aimed at making it more obvious that you can do this.)

[kmiller68]

I'm glad you don't think it's hard in V8 but having done this in JSC it took a lot of work (4-6 months and it still has perf cliffs). I also find it amusing that the design you wrote up is the design I think TC-39 should have gone with from the start.

[ljharb]

It’s not possible for JS to have a sentinel value, though, unless you make that value impossible to have an iterator produce.

[tabatkins]

Right, that's exactly what you'd do. (An iterator wanting to produce it anyway would have to wrap it in something, like an array.)