We still an an option open to us, that would merely compatibly remove a restriction from the language rather than add a feature: Allow labels to remain visible across function boundaries, or at least across arrow function boundaries. Then one could break-to-label to a label of a lexically enclosing function.
This has repeatedly died in committee before because it does raise another case for implementors: Once the execution context of that label has completed, an attempt to break to that label must instead throw an error. I've never understood why this extra case was a show stopper. Previous iterations of the proposal never raised the possibility of restricting this new ability to arrow functions. I don't see why we should, but I can see why it would seem more parsimonious -- since arrow functions are trying to be much more TCB than other functions. Perhaps that restriction will make this more palatable? In any case, even if we first allow this only for arrow functions, we'd still have the option to compatibly remove the restriction for other functions later. My other suspicion: The previous failure of this proposal was before many people had much hands on experience using higher order functions in JS as a normal alternative to control structures. Now that we all have, the need for a non-local escape may be more visceral. On Sun, Feb 22, 2015 at 11:36 PM, Dmitry Soshnikov < [email protected]> wrote: > On Sun, Feb 22, 2015 at 10:11 PM, Domenic Denicola <[email protected]> wrote: > >> My initial feedback is that this needs a lot more "why" in comparison >> to the "how". >> > > The technical reason for this I guess, is that JS doesn't have TCP blocks, > that would allow you to stop iteration, and exit the `reduce` context right > from the callback context. With TCP it would be a `return` statement, which > in JS we have to solve throwing a special "marker" exception, which should > be caught and analyzed. > > From the practical perspective, yeah, it would be good to see real > examples of how useful the feature is. Of course if we take the reason: > "exit from an hight-order iteration as soon as possible in a convenient > way", that could sound reasonable/practical. Although, to have concrete > examples would be good. > > However, I'd say, JS betters needs some sort of TCP blocks, which would > solve other similar cases (and which I'm pretty sure were discussed several > times couple of years ago). E.g. in Ruby that example would be much easier, > and that `@@reduced` would be just simple intuitive `return`. > > Dmitry > > > >> The only inkling of why this might be useful is an unsourced assertion >> that it's done in Clojure, for unknown reasons. The example code isn't very >> compelling either; something more real-world would be good there. >> ------------------------------ >> From: Lee Byron <[email protected]> >> Sent: 2015-02-23 00:58 >> To: [email protected] >> Subject: short-circuiting Array.prototype.reduce >> >> Hey all, >> >> I’d like to propose an addition to ES7 to add @@reduced as a way to >> short-circuit from Array.prototype.reduce. >> >> I’ve written up a polyfill and explanation here: >> >> https://github.com/leebyron/ecma-reduced >> >> I would love your feedback on this. >> >> Lee >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
