Should yield* preserve iteration result identity?

[littledan]

The runtime semantics for yield* seem to forward out the exact iteration result that was provided in the inner iterator. See step 6.a.iv. At the bottom of this post is a quick test I wrote to expose the semantics; the spec's semantics are implemented by 3/4 of the engines I tested.

In this V8 bug, some optimizations to generators are discussed. It seems that, if generators always output a new iteration result, it would be possible to move the iteration result allocation to the caller side, enabling unboxing even if the generator can't be inlined. @caitp prototyped this optimization and got a significant speedup. However, current yield* semantics don't permit this optimization, and @bmeurer judges it to be infeasible to make this work otherwise.

Alternate semantics are implemented by JSC (cc @kmiller68 @msaboff), where yield* always creates a new iteration result. For a naive implementation, the current specification may be slightly faster by avoiding the allocation in the yield* case, but in a more advanced implementation, JSC's semantics could enable a much greater level of avoiding allocations.

Does anyone have information about how the current yield* semantics were chosen?

cc @dherman @allenwb

---

Quick and ugly test differentiating the semantic options:

$ eshost -e "(function() { function* copy(iterable) { yield* iterable } let obj = { [Symbol.iterator]() { return { next() { return { value: 1, done: false, other: 123 } } } } }; let myCopy = copy(obj); return myCopy.next().other })()"
#### jsc
undefined

#### d8
123

#### chakracore
123

#### spidermonkey
123

[gskachkov]

In JSC we have a issue to fix this behaviour. cc @Constellation

[gskachkov]

In JSC we have a issue to fix this behaviour. cc @Constellation

[littledan]

@gskachkov Link to the issue?

[littledan]

@gskachkov Link to the issue?

[gskachkov]

Should be that one https://bugs.webkit.org/show_bug.cgi?id=174756

[gskachkov]

Should be that one https://bugs.webkit.org/show_bug.cgi?id=174756

[caitp]

I’m not sure we should fix it unless there’s a good reason to with real code depending on the identity preserving behaviour.

[caitp]

I’m not sure we should fix it unless there’s a good reason to with real code depending on the identity preserving behaviour.

[littledan]

I think there's value in all implementations being on the same page about which value is returned where.

[littledan]

I think there's value in all implementations being on the same page about which value is returned where.