OK, he isn't going to try to defend the described behavior as sensible. Is anyone?
Is there a single person willing to say not just that the intentions were good but that the actual outcome -- helper methods becoming part of the iteration protocol -- was correct? I'm listening very carefully to hear anyone voice that opinion, and so far I have not heard it.
Helper methods aren't part of the iteration protocol. They're a part of the Iterator class interface. If you want to take an arbitrary thing that implements the iteration protocol, you can use Iterator.from to get an instance of the Iterator class, which has more behavior than just the iteration protocol. This is all sensible and I'm quite happy with the design and its effects.
As long as you're taking bets, would you care to take a bet on who wrote those types? Do you think the author would agree with you?
Helper methods weren't part of the iteration protocol, but they certainly are now, beyond any doubt.
If they aren't part of the protocol, that would self-evidently mean, to me, that non-protocol methods are never used to bypass the protocol methods for communication. But that is happening, so the methods are part of the protocol, even though that was not the intention of the language designer.
Unfortunately it's not easy to see who wrote the types. I'm assuming you mean that you did, since I know you are also a TS contributor.
interface IteratorConstructor extends IteratorObjectConstructor {
from<T>(
value: Iterator<T, unknown, undefined> | Iterable<T, unknown, undefined>
): IteratorObject<T, undefined, unknown>; // No. Wrong. Not necessarily
}
I think that to be correct given the current implementation the types need to be:
interface IteratorConstructor extends IteratorObjectConstructor {
from<T, V extends Iterable<T, unknown, undefined>>(
value: V
// changed return type
): V extends IteratorObject ? V : IteratorObject<T, undefined, unknown>;
}