Jason Orendorff
Jason Orendorff
I think pretty much all of the trivia goes away if we change abrupt **break** and **continue** completion so that they always have [[Value]]: **undefined**.
That would of course be a breaking change. It would make the rules a snap to reason about, though: * It's easy to see statically which statement values matter and...
Oh, I guess actually getting the above rules would involve changing `var` and `let` to produce `undefined` as well. Further breakage. Likely too much... I guess we could try it.
I think the hazard is when you're the author of a widely used open source JS package. Your users can do arbitrarily silly things, like relying on individual function names...
Has this spectre of observability in fact caused a library author not to make a change, that we know of?
> I am a relatively prolific open source maintainer (200+ packages on npm, in various "top N" lists for downloads, etc) and I desperately want this so that I can...
OK, I think I have to disagree, but I see where you're coming from. Thanks for talking this out. This was really helpful.
(background: hi, my name is @jorendorff and my role in TC39 is to complain that the proposal README doesn't have good examples)
Right. A less contrived example would be an improvement, but that's not the main issue. I'm after evidence that sending values to generators has proven valuable enough to justify further...
I guess with iterators I really feel like we're on solid ground, if only because I use them myself all the time (not really joking, unfortunately), so the Iterator methods...