Normative: re-use IteratorResult objects in some iterator helpers

[michaelficarra]

This re-uses IteratorResult objects when it's possible to just pass the object through. There are currently 3 cases of this: take/drop/filter. See related PR for the iterator sequencing proposal, which also has this opportunity: tc39/proposal-iterator-sequencing#18

I actually don't like doing this for filter since filter observes the value, which would mean triggering a value getter both for filtering and by the eventual consumer.

[nicolo-ribaudo]

which would mean triggering a value getter both for filtering and by the eventual consumer.

Why do you consider this to only be bad for the .value getter and not for the .done getter, which would be double-triggered by all those methods?

[michaelficarra]

I think an expensive value getter is more likely than an expensive done getter.

[michaelficarra]

@nicolo-ribaudo Also, someone might be surprised that the resulting iterator yields values for which the predicate would return false. But we might just want to say 🤷‍♂️ getters admit weirdness.

edit: I've added a slide to the upcoming presentation covering interactions with getters.

[dminor]

@anba Do you have an opinion on this change?

[anba]

This change is possibly difficult to implement for JSC and SM, because both use self-hosted JS for their implementation and the proposed changes can't be easily implemented in JS. (yield* can't be used, because it performs one final IteratorValue when done, which is user-detectable.)

I guess this also applies to tc39/proposal-iterator-sequencing#18.

[michaelficarra]

because both use self-hosted JS for their implementation and the proposed changes can't be easily implemented in JS

Do you mean that they can't be easily implemented in JS at all, or do you mean using generators in JS? It seems manual iteration in JS should work fine.

yield* can't be used, because it performs one final IteratorValue when done, which is user-detectable

I'm open to also requiring the final IteratorValue to fully match a simpler generators/yield* implementation. One extra unnecessary property access at the end seems to be worth the savings of a whole extra object per item yielded.