JEP325: Switch expressions spec

[Brian Goetz]

One thing that is relevant to the short term is that now that we killed 
mixed labels, we'd have to have a way to say "case null or default" in 
arrow world.  The least stupid thing seems to be to allow default to be 
tacked on to a comma-separated case list as if it were a pattern:

     case A -> s1;
     case null, default -> s2;

since you can no longer say:

     case A -> s1;
     case null:
     default:
         s2;


On 4/20/2018 2:36 PM, Kevin Bourrillion wrote:
> On Fri, Apr 20, 2018 at 10:45 AM, Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>>     So, all I'm asking is: can we make this particular change
>>     atomically with patterns itself, not before? I believe that the
>>     change has negative value until then because it is too easy to
>>     use it to write bugs. (If this means that long and booleanalso
>>     wait until then, I don't think anyone would really mind. If
>>     necessary I can look up how common
>>     simulated-switch-on-longhappens in our codebase, but we all know
>>     it won't be much.)
>     The extra primitive types are separable, so could be deferred. 
>     I'd be less sanguine about adding long now but not float.
>
>
> Agreed, it would seem weird to keep adding more piecemeal over and over.
>
>>     Separately but similarly, the merits of case null: have also been
>>     justified almost entirely in the context of patterns. Without
>>     patterns, I believe the benefits are far too slight. We studied
>>     six digits' worth of switch statements in the Google codebase,
>>     using a /liberal/ interpretation of whether they are simulating a
>>     null case, and came up with ... 2.4%.  (You will find that
>>     suspicious as hell, since it's the exact same percentage I cited
>>     for fall-through yesterday, but I swear it's a coincidence!)
>     More nervous about this.  Would rather start the education curve
>     on this earlier. And there are plenty of existing switches that
>     are wrapped with "if target != null" that would be clearer/have
>     less needless repetition by pushing the case null into the switch.
>
>
> Er - just clarifying that this is the /same/ 2.4% that I am referring 
> to. Of course, numbers will vary (and I concede that we are quite 
> toward the null-hostile end of the spectrum in our general dev 
> practices). Still, I'm sure we would not be making this change for 
> this reason alone, so it really is about this issue of "starting the 
> education curve earlier". Trying to figure out how much that matters.
>
> For what it's worth, Guava took the position at the start that, since 
> working with null is risky and problematic, it's /okay/ if code that 
> deals with null is uglier than code that doesn't. It's only natural, 
> so we don't bend over backwards to try to smooth it over. If that 
> decision has played /some/ /small/ part in helping shift the world 
> away from rampant overuse of null everywhere, we wouldn't regret it a 
> bit. I think JDK collections post-1.4 could say the same thing to a 
> larger degree. Okay, I guess this is just the "moral hazard" argument 
> stated a different way - sorry.
>
> (Full disclosure: if you accuse me of wanting more time before `case 
> null:` lands just so I have more time to try to talk us out of it 
> completely, I suppose have no defense to that. :-))
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com 
> <mailto:kevinb at google.com>

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