JEP325: Switch expressions spec

Guy Steele guy.steele at oracle.com
Mon Apr 23 18:20:22 UTC 2018


> 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;`.

Notice that so far I have said nothing about the “default and null” problem being a motivation.  It’s all about preserving assumption (1).

The issue with default and null has nothing to do with the issue of arrow versus colon.  It *does* have to do with the issue of repeating the `case` keyword versus listing multiple values (or patterns) by using commas after a single `case` keyword: `default` does not play well with the comma-separated case when you use colons, so there is no reason to expect it to play well when you use arrows.  Trying to make a special-case exception for `default` in the arrow case requires making a similarly ugly exception in the colon case if assumption (1) is to be preserved.

I argue that there is no need to make the special-case exception for `default`.  When you need to play that game (usually because null needs to be addressed), you cannot use the comma-separation syntax.  Instead, just say either

	case null: default: s;			(or, if you prefer, `default: case null: s;`)

or

	case null -> default -> s;		(or, if you prefer, `default -> case null -> s;`)

depending on whether your `switch` is using colon syntax or arrow syntax.  The latter is just two characters longer than `default, case null -> s;` and has a much simpler and more consistent underlying theory.

—Guy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180423/63c97c15/attachment-0001.html>


More information about the amber-spec-experts mailing list