<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Mar 15, 2018, at 2:13 PM, Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" class="">maurizio.cimadamore@oracle.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><p style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);" class="">So, from a language design perspective, 'return x' is wrong - but, as you point out, we already committed the original sin of having 'return == local return' for lambdas, so I'm not too convinced that we couldn't use the same story again here. E.g. when you say 'return', what you really mean is 'returning from the innermost context'. This could be a method (as usual), or a nested expression e.g. a lambda or a switch expression.</p><div class=""><br class=""></div></div></blockquote>We have method bodies and lambda bodies on one hand,</div><div>and we have switches and loops on the other.</div><div><br class=""></div><div>We use return to escape from the former, and break to</div><div>escape from the latter.</div><div><br class=""></div><div>Note that return may or may not take an expression,</div><div>while break never does, at present.</div><div><br class=""></div><div>So far so good.  Now we stir in expression switches.</div><div>Which side of the fence do they belong on?</div><div><br class=""></div><div>It seems to me that your position needs to argue</div><div>that e-switches belong with methods and lambdas,</div><div>because only return can take an expression.</div><div>If you can pull this off, then break doesn't need</div><div>to take an expression.</div><div><br class=""></div><div>Likewise, my position need to argue that giving "break" an</div><div>expression is reasonable.  I don't need to argue</div><div>that expression switches are similar to legacy</div><div>switches.  (But I'm trying to spike the argument</div><div>that it's hard to unify e-switches and s-switches,</div><div>so let's just fork the language with a new switch-like</div><div>feature for expressions.)</div><div><br class=""></div><div>But there are two reasons why e-switch doesn't</div><div>belong with method body and lambda body,</div><div>a shallow but strong one, and a deep one.</div><div><br class=""></div><div>Shallow but strong:  e-switches are obviously switches.</div><div><br class=""></div><div>Deep:  Lambda bodies and method bodies execute</div><div>in their own stack frames.  Any up-level references</div><div>must be to final locals (or fields).  Lambda bodies</div><div>and methods can execute at most one "return",</div><div>which tears down their frame.  Expressions,</div><div>including expression switches, execute in the</div><div>frame of the containing lambda body or method</div><div>and can read *and write* local variables.</div><div>Expressions are inherently local to a frame</div><div>and can imperatively side effect it.</div><div><br class=""></div><div>A "return" which in some contexts keeps the</div><div>stack frame and jumps somewhere is a weaker</div><div>return than today's return.  (Weaker meaning</div><div>less can be concluded by observing it in code.)</div><div><br class=""></div><div><div>So I can't group e-switch cases with lambda bodies.</div><div>I know some have performed this feat to their own</div><div>satisfaction, but it's hard for me, in a way that</div><div>seems deeper than just learning curve.</div><div><br class=""></div></div><div>By now we recognize that adding an expression</div><div>to "break" is no big deal; it's a new overloading.</div><div>I agree that it is open to the accusation that it's not</div><div>thrifty, that "return" already does that job.</div><div>But it seems to me the shallow and deep points</div><div>above answer the accusation.</div><div><br class=""></div><div>For me, the cost of making "break" do a new</div><div>trick is paid for by the benefit of not inventing</div><div>a new switch-like expression (like ?: for if/else),</div><div>and not having to weaken "return".</div><div><br class=""></div><div>— John</div></body></html>