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.go...@oracle.com
<mailto:brian.go...@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. |kev...@google.com
<mailto:kev...@google.com>
