Expression switch - an alternate proposal

[Remi Forax]

----- Mail original -----
> De: "Cay Horstmann" <cay.horstmann at sjsu.edu>
> À: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Jeudi 12 Avril 2018 06:50:35
> Objet: Re: Expression switch - an alternate proposal

> I've thought about this more and in the end decided to speak up. Over
> the years, I explained a substantial number of Java features to a very
> large number of people, and I generally have a pretty good idea of where
> people struggle. Anonymous inner classes, wildcards, constructor
> references, the unnamed module, you name it. With all of these features,
> I knew I had my work cut out explaining them, but I wasn't too bothered.
> 
> I am bothered by the proposed expression switch syntax.
> 
> When I read these discussions about colons vs. arrows, I fear that they
> mask a much bigger issue. I do not think that there is significant
> transfer from the existing switch statement to what we want to achieve
> with expression switch. The matching part is similar, but the control
> flow is not.

the control flow of an expression switch is a subset of the control flow of a statement switch because it's an expression.

> 
> Maybe I am wrong. If there has been user testing that confirms that
> programmers properly transfer their knowledge of statement switch to
> expression switch with the "break x" syntax, that's great, and I'll shut
> up. In absence of such evidence, I would urge (1) to make expression
> switch visibly different from statement switch and (2) have an ironclad
> justification for "break x" or abandon it. It has tension with labeled
> break and classic break which can be present inside a branch of an
> expression switch. Teaching a break/return analogy does not seem any
> easier than teaching about block expressions.

You can not have a break label (or a continue) inside a switch expression, again it's an expression, it's like ?:, you can have a break label into it.

I disagree that teaching block expressions is as easy that teaching break expression, with block expressions, you also have to teach why you can not use it anywhere else in Java.
The break expression does not have this issue. BTW, i think it's easy in term of teaching to teach the switch expression first and then to teach the statement switch given that the expression switch semantics is a subset of the statement switch semantics.

> 
> Cheers,
> 
> Cay
> 
> 

Rémi

> 
> 
> Le 10/04/2018 à 13:59, Stephen Colebourne a écrit :
>> On 10 April 2018 at 09:02,  <forax at univ-mlv.fr> wrote:
>>>>> Basically, your proposal is to use -> eveywhere, i think i prefer the opposite,
>>>>> do not use arrow at all.
>> 
>> Current Oracle proposal:
>> statements = colon
>> expression = colon, with arrow for expressions
>> 
>> Alternate proposal:
>> statements = colon
>> expression = symbol-that-isnt-colon
>> 
>> Remi proposal:
>> statements = colon
>> expression = colon
>> 
>> If the goal is a unified switch expression, Remi proposal wins. It is
>> dead simple and very consistent.
>> 
>>>> This is a reasonable alternative, but I don't think it would be very
>>>> popular.  I think people will really love being able to write:
>>>>
>>>>      case MONDAY -> 1;
>>>>      case TUESDAY -> 2;
>>>>
>>>> and will be sad if we make them write
>>>>
>>>>      case MONDAY: break 1;
>>>>      case TUESDAY: break 2;
>> 
>> Meh. Three more characters.
>> 
>> Yet:
>> - Avoids the arrow having a conflict of meaning with lambda.
>> - No mixed arrows & colons
>> - Much more consistent.
>> - Minimal change from existing switch.
>> - Less to learn.
>> Win, win, win.
>> 
>> So while I'd still choose to have a separate symbol for expression and
>> statement switches (because of my #1 goal), I'm also pretty fine with
>> the Remi proposal (because my #2 goal).
>> 
>> In fact, what the discussion has informed me is that my #1 and #2
>> goals are the wrong way around. Getting rid of the mixed arrows and
>> colons is now more important to me than understanding the context in a
>> large switch.
>> 
>> Stephen
>> 
> 
> 
> --
> 
> Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com