You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.
Comment
🔎 Search Terms
iterator generator yield next
🕗 Version & Regression Information
Current behaviour has existed since 3.6.0.
With upcoming changes to iterators, I wonder whether it might be worth quickly revisiting the behaviour of the next() iterator method.
As discussed at #30790, when interacting with iterators manually, the compiler will always consider it valid if next() is called with zero-arity, even if TNext is of a type that cannot be void/undefined. The rationale for allowing this is that the iterator interface also has to be implemented by generators, where any parameter passed to the first call to next() gets thrown away, so it should be valid to allow the parameter to be absent.
This does have some type safety implications as originally discussed, but this also causes a related problem with the type of the yield statement in generators, which I don't think has ever been raised before:
function*g(): Generator<null,string,number>{consta=yieldnull;// const a: numberreturna.toString(16);}constit=g();it.next();it.next();// TypeError: a is undefined
The function signature of next() allows the second call to be made without a parameter, but the compiler assumes that the type of the yield statement will always be TNext, and never be undefined. Although it violates the semantic intention of the generator signature, it seems like yield potentially returning undefined is a forced possibility if next() always allows calls with zero parameters, which was discussed previously and considered necessary.
Even if there's no alternative way to define next(), I wonder if the question of how to handle yield specifically needs considering. There was a mention in the design meeting minutes of considering new flags relating to iterators – maybe there's a case for one here?
Acknowledgement
Comment
🔎 Search Terms
iterator generator yield next
🕗 Version & Regression Information
Current behaviour has existed since 3.6.0.
With upcoming changes to iterators, I wonder whether it might be worth quickly revisiting the behaviour of the
next()
iterator method.As discussed at #30790, when interacting with iterators manually, the compiler will always consider it valid if
next()
is called with zero-arity, even ifTNext
is of a type that cannot be void/undefined. The rationale for allowing this is that the iterator interface also has to be implemented by generators, where any parameter passed to the first call tonext()
gets thrown away, so it should be valid to allow the parameter to be absent.This does have some type safety implications as originally discussed, but this also causes a related problem with the type of the
yield
statement in generators, which I don't think has ever been raised before:The function signature of
next()
allows the second call to be made without a parameter, but the compiler assumes that the type of theyield
statement will always beTNext
, and never be undefined. Although it violates the semantic intention of the generator signature, it seems likeyield
potentially returning undefined is a forced possibility ifnext()
always allows calls with zero parameters, which was discussed previously and considered necessary.Even if there's no alternative way to define
next()
, I wonder if the question of how to handleyield
specifically needs considering. There was a mention in the design meeting minutes of considering new flags relating to iterators – maybe there's a case for one here?related: #58243
The text was updated successfully, but these errors were encountered: