JEP325: Switch expressions spec

[Brian Goetz]

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

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


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