<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body style="background-color: rgb(255, 255, 255); color: rgb(0, 0,
    0);" text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    <br>
    May I jump in as an outsider and someone who's just using the
    language...<br>
    <br>
    <div class="moz-cite-prefix">On 03/15/18 22:58, John Rose wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:F0F4D2C5-AEE4-438F-A0EF-A44D0F53C3E5@oracle.com"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]-->
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      On Mar 15, 2018, at 2:13 PM, Maurizio Cimadamore <<a
        href="mailto:maurizio.cimadamore@oracle.com" class=""
        moz-do-not-send="true">maurizio.cimadamore@oracle.com</a>>
      wrote:<br class="">
      <div>
        <blockquote type="cite" class=""><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]--><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>
          <!--[if !IE]></DIV><![endif]--></blockquote>
        We have method bodies and lambda bodies on one hand,</div>
      <div>and we have switches and loops on the other.</div>
      <!--[if !IE]></DIV><![endif]--></blockquote>
    <br>
    Yes, and my intuitive distinction between those two kinds of
    constructs is that the first are just "declarations" of code blobs,
    while the second are code blobs that execute in-line with the
    surrounding code. It is therefore very intuitive for me to have two
    kinds of syntax for exiting the constructs - "return" for the first
    and "break" for the second.<br>
    <br>
    I don't know why others find break so archaic. When I 1st saw this
    proposal, I thought that break was very intuitive choice for
    e-switch.<br>
    <br>
    <blockquote type="cite"
      cite="mid:F0F4D2C5-AEE4-438F-A0EF-A44D0F53C3E5@oracle.com"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]-->
      <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>
      <!--[if !IE]></DIV><![endif]--></blockquote>
    <br>
    That's another, more technical way of saying: methods and lambdas
    are declarations of code, switches and loops are in-line constructs
    that execute "immediately" in the surrounding context. Lambdas do
    "capture" surrounding context, but they don't execute in it (they
    can't modify locals, do long returns etc.).<br>
    <br>
    Speaking of long returns...<br>
    <br>
    If return was used for "yielding" a result from e-switch, how is one
    supposed to do a return from a method inside the e-switch:<br>
    <br>
    int m(int x) {<br>
        int y = switch (x) {<br>
            case 1: return 12; // I want to return from m() here!<br>
        }<br>
    }<br>
    <br>
    <blockquote type="cite"
      cite="mid:F0F4D2C5-AEE4-438F-A0EF-A44D0F53C3E5@oracle.com"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900;  padding: 0px 15px; margin: 2px 0px;"><![endif]-->
      <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>
      <!--[if !IE]></DIV><![endif]--></blockquote>
    <br>
    I totally agree. There are some caveats though. What to do in
    situations like this, for example:<br>
    <br>
    int var_or_label = 13;<br>
    int y = switch (x) {<br>
        case 1: <br>
            var_or_label: {<br>
                break var_or_label;<br>
            }<br>
            // do we reach here?<br>
    };<br>
    <br>
    <br>
    The standard means that Java took to avoid ambiguities caused by new
    features was to prioritize old behavior (varargs for example). In
    above sample, label would take precedence. It is easy to choose the
    var:<br>
    <br>
        break (var_or_label);<br>
    <br>
    <br>
    And now for something completely different...<br>
    <br>
    I think that with introduction of e-switch, we might soon see it
    being "abused" for things like:<br>
    <br>
    doSomething(<br>
        par1,<br>
        switch (1) { case 1:<br>
            // compute result...<br>
           break resut;<br>
        },<br>
        par3<br>
    );<br>
    <br>
    Are there any plans for such construct "without the boilerplate" ?-)<br>
    <br>
    Among existing reserved words, "do" seems most appropriate:<br>
    <br>
    doSomething(<br>
        par1,<br>
        do {<br>
            // compute result...<br>
           break resut;<br>
        } while (false),<br>
        par3<br>
    );<br>
    <br>
    And if "while (false)" could be optional, we get:<br>
    <br>
    doSomething(<br>
        par1,<br>
        do {<br>
            // compute result...<br>
           break resut;<br>
        },<br>
        par3<br>
    );<br>
    <br>
    Combining with lambdas, we get 3 ways to do the same thing:<br>
    <br>
    x -> y<br>
    x -> { return y; }<br>
    x -> do { break y; }<br>
    <br>
    <br>
    Regards, Peter<br>
    <br>
  </body>
</html>