Expression switch - an alternate proposal

[Brian Goetz]

This underscores exactly the point I made in my last mail about the 
spectrum of different ... Different .. #{ DIFFERENT }, and subjective 
perceptions thereof -- while Stephen is satisfied with a little more 
rigidity to the structure of the body to provide the "hey, I'm a 
different construct" signal, Cay finds that too subtle, and would prefer 
a different keyword.

And again, this has all been said before:

https://thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/


On 4/9/2018 10:15 AM, Cay Horstmann wrote:
> Stephen is right about accentuating the common matching, while making it
> easy to tell the difference between expressions and statements. I suggest
> this to  make the expression syntax look a little different:
>
> var action = light switch {
>     case ...
>     case ...
> };
>
> Like an instanceof expression, or a Scala match expression without a new
> keyword. Then you can keep case : (or stick with case ->).
>
> Cheers,
>
> Cay
>
> 2018-04-08 16:58 GMT-07:00 Stephen Colebourne <scolebourne at joda.org>:
>
>> What follows is a set of changes to the current expression switch
>> proposal that I believe result in a better outcome.
>>
>> The goal is to tackle four specific things (in order):
>> 1) The context as to whether it is a statement or expression switch
>> (and thus what is or is not allowed) is too remote/subtle
>> 2) Mixing arrows and colons is confusing to read
>> 3) Blocks that do not have a separate scope
>> 4) Fall through by default
>> while still keeping the design as a unified switch language feature.
>>
>> To tackle #1 and #2, all cases in an expression switch must start with
>> arrow -> (and all in statement switch must start with colon :)
>> To tackle #3, all blocks in an expression switch must have braces
>> To tackle #4, disallow fall through in expression switch (or add a
>> fallthrough keyword)
>>
>> Here is the impact on some code:
>>
>> Current:
>>
>>   var action = switch (light) {
>>     case RED:
>>       log("Red found");
>>       break "Stop";
>>     case YELLOW:
>>     case GREEN -> "Go go go";
>>     default:
>>       log("WTF: " + light);
>>       throw new WtfException("Unexpected color: " + light);
>>   }
>>
>> Alternate proposal:
>>
>>   var action = switch (light) {
>>     case RED -> {
>>       log("Red found");
>>       break "Stop";
>>     }
>>     case YELLOW, GREEN -> "Go go go";
>>     default: -> {
>>       log("WTF: " + light);
>>       throw new WtfException("Unexpected color: " + light);
>>     }
>>   }
>>
>> How is this still a unified switch? By observing that switch can be
>> broken down into two distinct phases:
>> - matching
>> - action
>> What makes it unified is that the matching phase is shared. Where
>> statement and expression switch differ is in the action phase.
>>
>> The unified matching phase includes:
>> - target expression to switch on
>> - case null
>> - constant case clauses
>> - pattern matching case clauses
>> - default clause
>>
>> The action phase of a statement switch is:
>> - followed by a colon
>> - have non-scoped blocks
>> - fall through by default
>> - can use return/continue/break
>>
>> The action phase of an expression switch is:
>> - followed by an arrow
>> - have an expression or a block (aka block-expression)
>> - cannot fall through
>> - cannot use return/continue/break
>>
>> By having a unified matching phase and a separate (but consistent)
>> action phase in each form, I believe that the overall language feature
>> would be much simpler to learn. And importantly, it achieves the goal
>> of not deprecating or threatening the existence of the classic
>> statement switch.
>>
>> All the key differences are in the action phase, which is clearly
>> identified by arrow or colon (no remote context). Developers will come
>> to associate the rule differences between the two forms with the arrow
>> or colon, while the pattern matching knowledge is shared.
>>
>> Of course, the matching phase is not completely unified - expression
>> switches must be exhaustive, and they may have auto default case
>> clauses. (Perhaps the unified matching phase mental model suggests
>> that auto default would be better written explicitly, eg. "default
>> throw;", which could then apply to both statement and expression. Not
>> sure.)
>>
>> I hope this alternate proposal is clear. To me, the split between a
>> unified matching phase and a consistent but different action phase
>> clearly identified in syntax results in much better readability,
>> learning and understandability.
>>
>> Stephen
>> PS. I think there are alternate block expression syntaxes, including
>> ones that avoid "break expression", but I've chosen to avoid that
>> bikeshed and use the closest one to the current proposal for the
>> purpose of this mail
>>