JEP325: Switch expressions spec
Brian Goetz
brian.goetz at oracle.com
Fri Apr 20 17:45:12 UTC 2018
> 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>
More information about the amber-spec-experts
mailing list