New JEP: Switch Expressions for the Java Language
Brian Goetz
brian.goetz at oracle.com
Mon Dec 11 20:15:43 UTC 2017
>
>> * Should we make it possible to use the new expression switch
>> construct in non-expression contexts? Any values returned by a
>> case would be ignored. Optionally we could skip requiring default
>> to be present (meh). Users may want this because it's really nice
>> to not have to write "break" anymore. They may also want it if we
>> answer "no" to either or both of the previous two questions. It's
>> also kind of nice that each case gets its own separate scope,
>> although they can get that by inserting braces anyway.
>>
In order for it not to be painful to turn a statement switch into an
expression switch, we'd have to support void-typed expression switches.
Then you could write something like this:
switch (target) {
case X -> println("x");
case Y -> println("y");
}
But expressions can't have void type (among other reasons, it's not a
type, at least not yet), so we'd have to carve out a special case for
this if we wanted to support it. And this would further muddy the
differences, and call for a number of other special cases (e.g., how
would I write the default clause?)
So as long as we don't bend over backwards to try and special-case void
expression switches (we don't for conditional expressions), I think
"there's expression switch and statement switch; using either to
simulate the other is painful, so don't" leads to a good place.
(Note to observers: the goal of this exercise here is not to fix what
people hate about statement switch; it's about (a) laying the groundwork
for pattern matching while (b) factoring out some generally-useful
enhancements that can be exposed earlier.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20171211/b148e390/attachment.html>
More information about the amber-spec-experts
mailing list