<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<tt>Updated.</tt><br>
<br>
<div class="moz-cite-prefix">On 12/19/2017 3:03 PM, Guy Steele
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:246C3EE2-9C15-4DE3-8336-C5494EB4D05B@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Good.
<div class=""><br class="">
</div>
<div class="">This sentence:</div>
<div class=""><br class="">
</div>
<div class=""> The sugared form of case arms
of switch expressions may also throw exceptions, even
though throw e is a statement, not an expressions. </div>
<div class=""><br class="">
</div>
<div class="">(“an expressions”??) could perhaps be replaced or
augmented by this syntactically more precise observation:</div>
<div class=""><br class="">
</div>
<div class=""> In a switch expression, we also define</div>
<div class=""><br class="">
</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case
LABEL -> throw expression;</div>
<div class=""><br class="">
</div>
<div class=""> to be sugar for</div>
<div class=""><br class="">
</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case
LABEL: throw expression;</div>
<div class=""><br class="">
</div>
<div class="">Also, there is a formatting problem: the text line</div>
<div class=""><br class="">
</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>System.out.println("Neither
Foo nor Bar, hmmm..."); break 3; }</div>
<div class=""><br class="">
</div>
<div class="">should have been part of the code in the preceding
box.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">On Dec 19, 2017, at 2:40 PM, Brian Goetz <<a
href="mailto:brian.goetz@oracle.com" class=""
moz-do-not-send="true">brian.goetz@oracle.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> <tt
class="">I've updated the JEP to reflect these
proposed changes:<br class="">
<br class="">
<a class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8192963"
moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8192963</a><br
class="">
</tt><br class="">
<div class="moz-cite-prefix">On 12/14/2017 4:22 PM,
Brian Goetz wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:3d1f794f-4694-32ee-a56c-d82d1d9e05f1@oracle.com"
class="">
<meta http-equiv="content-type" content="text/html;
charset=utf-8" class="">
<div class="moz-text-flowed" style="font-family:
-moz-fixed; font-size: 14px;" lang="x-unicode"><br
class="">
After reviewing the feedback on the proposal for
switch expressions, and a bit of going back to the
drawing board, I have some proposed changes to the
plan outlined in the JEP. <br class="">
<br class="">
<br class="">
1. Throw expressions. While throw expressions are
a reasonable feature, many expressed concern that if
permitted too broadly (such as in method invocation
context), they would encourage "tricky" code for
little incremental expressiveness. The real need
here is for arms of expression switches to be able
to throw when an unexpected state is encountered;
secondarily it may be useful allow a value-bearing
lambda to unconditionally throw as well. But
extending this to &&, ||, assignment, and
method invocation context seems like asking for
trouble. So we'll narrow the treatment here,
allowing throw on the RHS of a switch expression
ARM, and possibly also the RHS of a lambda. (This
doesn't close any doors on making `throw` an
expression later, if desired.)<br class="">
<br class="">
<br class="">
2. Local return from switch. In the proposal, we
borrowed the convention from lambda to use "return"
for nonlocal return, mostly on the theory of "follow
the arrow". But this is pretty uncomfortable, made
worse by several factors: a) despite the syntactic
similarity, we don't follow exactly the same rules
for case arms of expression switches as for lambdas
(such as treatment of captured vars), and b) when
refactoring from statement switch to expression
switch or vice versa, there's a danger that an
existing "return" could silently swap between
nonlocal and local return semantics. <br class="">
<br class="">
So we dusted off an old idea, which we'd previously
explored but which had some challenges, which is to
use "break" with an operand instead of "return" to
indicate local return in switch expressions. So: <br
class="">
<br class="">
int y = switch(abs(x)) { <br class="">
case 1 -> 1; <br class="">
case 2 -> 2; <br class="">
case 3 -> 3; <br class="">
default -> { <br class="">
println("bigger than 3"); <br class="">
break x; <br class="">
} <br class="">
}; <br class="">
<br class="">
The challenge is ambiguity; this could be
interpreted as a nonlocal break out of an enclosing
loop whose label is `x`. But then we realized that
if `x` is both a variable and a label, we can just
reject this, and tell the user to rename one or the
other; since alpha-renaming the label is always
source- and binary-compatible, the user has at least
one (if not two) reasonable choices to get out of
this problem. <br class="">
<br class="">
The benefit here is that now "break" means basically
the same thing in an expression switch as it does in
a statement switch; it terminates evaluation of the
switch, providing a value if one is needed. Having
addressed the ambiguity problem, I think this is a
slam-dunk, as it aligns expression switch and
statement switch quite a bit (same capture rules,
same control flow statements.) We can also, if we
like, support "break" for local return in lambdas
(we should have done this in 8), to align the two. <br
class="">
<br class="">
<br class="">
3. (Optional.) There's room to take (2) farther if
we want, which is to complete the transformation by
eliminating the fake "block expression" in favor of
something more like existing switch. The idea would
be to borrow from statement switches, and rewrite
the above example as (note where we use colon vs
arrow): <br class="">
<br class="">
int y = switch(abs(x)) { <br class="">
case 1 -> 1; <br class="">
case 2 -> 2; <br class="">
case 3 -> 3; <br class="">
default: <br class="">
println("more than 3"); <br class="">
break x; <br class="">
}; <br class="">
<br class="">
So in this context, then "case L -> e" in an
expression switch is just sugar for "case L: break
e". As with lambdas, I expect the statements+break
form to be pretty rare, but we still need to have a
way to do it (not all objects can be created in a
single expression without resorting to stupid
tricks.) <br class="">
<br class="">
A good way to think about this is that this is
leaving statement switch completely alone, and then
expression switch "extends" statement switch, adding
the nice arrow shorthand and the exhaustiveness
analysis. The downside is that expression switch is
even more "infected" by existing switch semantics,
but after thinking about it for a while, this
doesn't bother me. (It's more uniform, plus its
considerably harder to make the "accidental
fallthrough" mistake in an expression switch than a
statement switch.) <br class="">
<br class="">
I expect this proposal will be a little more
controversial than (2) -- mostly because some are
probably holding out hope that we'd radically rework
existing switch -- but it has the major advantage of
further building on existing switch, and also
refrains from introducing a similar but different
kind of fake block expression. Overall this is is
more of a "build on what's there" solution, rather
than "add something new in the gap." <br class="">
<br class="">
<br class="">
</div>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br>
</body>
</html>