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>