Expression switch - an alternate proposal

[Cay Horstmann]

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.

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.

Cheers,

Cay




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