On Mon, Oct 22, 2018 at 7:47 PM, <[email protected]> wrote: > Here's one I'd like: > for (int i = ...; test(i); i = next(i)) { > if (good_stuff(i)) { break; /* goto past `else` block */ } > } else { > /* test(i) failed, i.e., we didn't `break` */ > do_something(i); // decls inside `for(...)` still in scope. > } > and/or: > for (auto& x: xs) { > if (good_stuff(x)) { break; /* goto past `else` block */ } > } else { > /* went off-range, i.e., we didn't `break` */ > }
This has actually been proposed before! Here's the latest iteration of the proposal (dated February 2017): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0082r2.pdf and here's my summary of its discussion, from my blog post about the meeting where it was discussed [1]: "An updated version of for loop exit strategies, which proposes to allow adding blocks of code at the end of a for loop that run when the loop exits by breaking (introduced by the keyword on_break), and when the loop runs to completion (introduced by on_complete). The only thing that has changed since the last revision of this proposal is the keywords – they were catch break and catch default in the previous version. EWG didn’t love the new keywords, either, and was generally lukewarm towards the proposal in terms of motivation, so it’s not clear if this is going anywhere." Given that this has already been proposed and effectively shot down, I think it makes to try and re-propose it only if we have new information to bring to the table, e.g. compelling new motivation or a design alternative that hasn't been considered. Cheers, Botond [1] https://botondballo.wordpress.com/2017/03/27/trip-report-c-standards-meeting-in-kona-february-2017/ _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
