JEP325: Switch expressions spec

[Brian Goetz]

Please, let’s not cross-post between amber-spec-* and amber-dev.  The -dev list is not for language design discussions.  

> On Apr 24, 2018, at 9:28 AM, Ali Ebrahimi <ali.ebrahimi1781 at gmail.com> wrote:
> 
> Hi,
> 
> On Mon, Apr 23, 2018 at 10:50 PM, Guy Steele <guy.steele at oracle.com> wrote:
> 
>> 
>>> On Apr 23, 2018, at 2:02 PM, Kevin Bourrillion <kevinb at google.com>
>> wrote:
>>> 
>>> On Fri, Apr 20, 2018 at 11:55 AM, Guy Steele <guy.steele at oracle.com
>> <mailto:guy.steele at oracle.com>> wrote:
>>> 
>>> You know, if s2 is short (say, less than 30 or 40 characters), there are
>> worse things than writing
>>> 
>>>         case A -> s1;
>>>         case null -> s2;
>>>         default   -> s2;
>>> 
>>> especially if you use spaces (as I just did) to line up the two
>> occurrences of s2 to make it easy to see they are identical.
>>> 
>>> And if s2 is long, there are worse things than making a little sub
>> method to handle it:
>>> 
>>>         case A -> s1;
>>>         case null -> frobboz(a, b);
>>>         default   -> frobboz(a, b);
>>> 
>>>    int frobboz(int a, String b) { … }
>>> 
>>> And if even THAT is not satisfactory, well, there are worse things than
>> giving up on the arrows and just using colons (and break, if needed).
>>> 
>>> I think neither of these goes down well. Having to repeat yourself at
>> all, while normal cases get to use comma, will feel very wrong. Having to
>> abandon arrowform over this would be even worse.
>>> 
>>> 
>>> BUT, on the other hand, if we wanted to: instead of, or in addition to,
>>> 
>>>        case pat1, pat2, pat3 -> s;
>>> 
>>> we could allow the form
>>> 
>>>        case pat1 -> case pat2 -> case pat3 -> s;
>>> 
>>> This seems like a step backward to me (whether it is instead or in
>> addition).
>>> 
>>> fwiw, I think `default, case null ->` is superior to all of these
>> options.
>> 
>> As an ad-hoc patch that solves this one problem, I agree.
>> 
>> But let me make a revised pitch for allowing it “in addition to” (which,
>> now that I have pondered it over the weekend, I think is clearly the
>> correct approach).
>> 
>> (1) We have moved toward allowing “arrow versus colon” to be a syntax
>> choice that is COMPLETELY orthogonal to other choices about the use of
>> `switch`.  If this rule is to hold universally, then any switch statement
>> or expression should be convertible between the arrow form and the colon
>> form using a simple, uniform rule.
>> 
>> (2) In switch expressions we want to be able to use the concise notation
>> `case a, b, c -> s;` for a switch clause.
>> 
>> (3) From (1) and (2) we inexorably conclude that `case a, b, c: break s;`
>> must also be a valid syntax.
>> 
>> (4) But we could also have written (3) as `case a: case b: case c: break
>> s;` and we certainly expect them to have equivalent behavior.
>> 
>> (5) From (1) and (4) we conclude that we ought also be to be able to write
>> `case a -> case b -> case c -> s;`.
>> 
> I think you have missed one rule arrow arms don't support fall-through
> (assume they have an explicit break).
> So
> *case a -> case b -> case c -> s;  *
> Would be equivalent to
> if in statement switch
> *case a : break; case b : break; case c : S; break ; *
> But in expression switch
> *case a : break; case b : break; case c : break S ;*
> Is an compile error, since some case labels breaks without value for
> expression switch.
> 
> So we can say that
>    *case a, b, c: s;*
> Can be refactored to
>    *case a: case b: case c: s;*
> But
> 
> *case a, b, c-> s;*
> Can't be refactored to
> *:*
> 
> * case a -> case b -> case c -> s;  *
> Rational: as we saw above they are not actually equivalent.
> -- 
> Best Regards,
> Ali Ebrahimi