JEP proposed to target JDK 12: 325: Switch Expressions (Preview)

[Remi Forax]

Stephen,
We do not need to introduce a new expression form because we already have the arrow syntax and we do not need another keyword because we want to retrofit old switches.

We have two goals:
1. We want to get ride of the existing scope rules and to disallow fallthrough, and even more than that, we want to allow users to be able to retrofit their old switch statement which doesn't fallthrough (so using another keyword than switch doesn't help).
2. There is a need for a statement that can have an expression as result, we re-use the arrow syntax of the lambda because it's exactly a statement expression and it already exists in the language*. In these statements, using return means returning from the method hence the break expression.

So you have a 2x2 matrix, a switch 
- is an expression or not
- disallow fallthrough or not

Apart from the statement switch and the expression switch, we have two others possibilities, a statement switch with no fallthrough (we want that) and an expression switch with fallthrough, you may not like this option but it allows to retrofit an old switch with fallthrough to be expression oriented, thus using a more functional style of writing.

regards,
Rémi

* you right that reusing -> can be confusing because until now you have only see -> in the context of a lambda. The other way to see that issue is to say that allowing to not have the parenthesis for a lambda with one parameter was a design mistake. Because it blurs the difference between an arrow statement and a lambda because the parameters of the lambda are not clearly visible. 
 

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> À: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Jeudi 23 Août 2018 14:16:25
> Objet: Re: JEP proposed to target JDK 12: 325: Switch Expressions (Preview)

> As I have expressed previously on amber-dev, I find the design adopted
> here to be overly complex and with a poor syntax choice. There are
> aspects to like, and the proposal is better than earlier versions. I
> also acknowledge that this is a proposal to create a preview language
> feature, however in all likelihood, there will be no further changes
> to the syntax/design once integrated as a preview.
> 
> Some specific objections:
> 
> (FYI, "classic" uses colon and has fallthrough-by-default, "enhanced"
> uses arrow -> and does not allow fall-through).
> 
> - the original goal was to add one new language feature (expression
> switch), yet the solution adds three (classic expression switch,
> enhanced statement switch & enhanced expression switch). This
> unnecessarily complicates Java for little gain IMO.
> 
> - all the evidence I've seen suggests that fallback in switch is very
> rare, and I'd strongly argue that most developers consider
> fallthrough-by-default to be a poor feature of Java. Adding a new
> language feature (classic expression switch) which adds more
> fallthrough-by-default is a mistake IMO. It is likely that style
> guides and best practice will recommend against using classic
> expression switch. I do not accept that consistency ("it makes a 2x2
> grid") is a sufficient reason to add a new language feature that will
> effectively be dead on arrival.
> 
> - the use of -> as the separator in enhanced switch is undesirable
> IMO. Objections to the syntax have also been made by some expert group
> members. The particular problem is that it means something different
> to the use of -> in lambda expressions. This can result in confusing
> semi-puzzlers, such as "case RED -> YELLOW -> 6";.
> 
> - the vast majority of existing switch statements would be more safely
> expressed using the enhanced form. As such, the enhanced form
> effectively replaces the classic form in Java - its that much better
> that classic statement switch will just be abandoned by developers
> IMO. Given this and the pointlessness of adding classic expression
> switch, the argument for using the keyword `switch` for the enhanced
> forms is weak IMO. At my presentations on the topic, the vast majority
> of developers have come to the conclusion that the enhanced form
> should use a different keyword, for example `match`, not `switch`.
> Doing so allows the colon to be used instead of the arrow:
> 
> var name = match (trafficLight) {
>  case RED: "Red";
>  case YELLOW: "Yellow";
>  case GREEN: "Green";
> };
> 
> - Adding a new keyword/symbol for the expression form (and potentially
> declaring it an ExpressionStatement instead of having a separate
> statement form) would IMO be a simpler approach to the problem space,
> potentially adding just 1 new form rather than 3 as proposed by the
> JEP.
> 
> 
> In summary, the world will not end if the JEP 325 progresses, and this
> proposal is much better than previous ones. However I believe that by
> taking the route of expanding `switch` rather than using a different
> keyword/symbol the result has been greater complexity than is
> necessary to meet the actual goal of "expression switch".
> 
> thanks
> Stephen
> 
> 
> On 17 August 2018 at 18:44,  <mark.reinhold at oracle.com> wrote:
>> The following JEP is proposed to target JDK 12:
>>
>>   325: Switch Expressions (Preview)
>>        http://openjdk.java.net/jeps/325
>>
>> Feedback on this proposal is more than welcome, as are reasoned
>> objections.  If no such objections are raised by 23:00 UTC on Friday,
>> 24 August, or if they’re raised and then satisfactorily answered, then
>> per the JEP 2.0 process proposal [1] I’ll target this JEP to JDK 12.
>>
>> - Mark
>>
>>
> > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html