`case null:` (here we go)

Tue May 1 16:39:13 UTC 2018

A few small follow-ups:

Upon further research, the statistic that 2.4% of our switch statements are
simulating `case null` has mostly held up - it's somewhere between 2.0 and
2.3%. (Note that our development practices are relatively null-hostile, so
the value would likely be higher in other codebases.)

But I also found that of *these*, 62-81% are doing it to give null the same
behavior as default. Compared to (of course) 19-38% giving null distinct
behavior. (That wide range is a 90% confidence interval and could be
narrowed if it were actually helpful.) So, what this tells us is that `case
null` without the ability to combine it with `default` would indeed be a
dissatisfying change.

However, having reviewed 67 samples (across both kinds) manually, I can
confirm that (so long as we do have the ability to combine `default` and
`case null` together) they do simplify pretty nicely with the proposed
change. I had expected to find a number of examples where null could
instead be canonicalized to another value, which would then enable the
switch to work as written. However, it's only worth doing that when it
"feels right" and not like a hack, and it turned out there were only a
small handful of examples like that.

So (as previously conceded) the change IS a win for these cases. The
question really is just about how hamstrung we are or aren't by the
decisions already set in stone for null switch in previous versions. My
data won't do anything to settle it; it comes down to a squishy judgment
call about what best protects whatever measure of conceptual simplicity
switch can hang onto.

ftr, my request continues to be only that we hold off on making any change
regarding null for now.

On Fri, Apr 27, 2018 at 8:59 AM, Kevin Bourrillion <kevinb at google.com>
wrote:

> From newest spec:
>
>
> *ClauseLabel*:
>
> *CasePattern ->*
>
> *CasePattern:*
>
> *case Pattern { , Pattern }*
> *default*
>
> *Pattern:*
>
> *ConstantExpression*
> *EnumConstantName*
> *null*
>
>
> Just a reminder that we still have this conflict to resolve. Even when you
> learn the wart that `default` is not covering null, there is no way to
> *make* it do so without repeating the RHS. We need `default, case null:`.
>
> Of course, my preferred resolution is to *hold off* on `case null`
> support for now. I'd like to give one honest attempt at a full argument; I
> hope to get an engaged response to it, and then if a decision is made
> against it, I'll move on, figure I was wrong, and never speak of it again.
> :-)
>
> ~~
>
> 1. For the sake of argument I'll just concede the notion that today's null
> behavior in switch was a mistake and if we could turn back time we would
> change it.
>
> 2. On the flip side, I think that proponents of the feature can probably
> concede that we would *never* have designed it in the now-proposed way
> for a fresh language; it *is* a permanent wart brought about by
> historical accident only. (Yes?) So, I assume that proponents recognize
> that rejecting this change is at least *defensible*, by appealing to the
> compatibility constraints we inherited. We should not need to worry that we
> will "look like idiots" (or whatever terms our deepest fears phrase
> themselves in :-)).
>
> 3. Many users since 2004 have said, and will continue to say, that they
> wish `case null` were allowed. However, I don't think we can assume they
> are necessarily comparing today's behavior to the *actual* feature we are
> proposing, with its warts. It is likely and natural that they are really
> comparing today's behavior to the time-machine feature of our having
> supported `case null` from the start. Therefore I think we have to take
> most such requests with a grain of salt.
>
> 4. Yes, sometimes users do write code that simulates `case null` and that
> code could be nicely simplified if null were allowed in switch. I can do a
> better job of quantifying the incidence of this need in our large codebase
>  if necessary (but have been prioritizing string literal research for
> now). But fundamentally, the feature *is* a win, for *these* examples.
>
> 5. It has been implied that patterns are what make the current null
> treatment "untenable". To me, I don't think this argument has been made
> convincingly yet. It seems to add up to "there may be a few more of those
> cases where you bump up against the prohibition and think 'oh yeah, grrrr,
> can't switch directly on null because of reasons no one understands!'" But
> fundamentally it seems like the same problem it already was.
>
> 6. That benefit has to be weighed against the damage we will be causing.
> Here is the meat of it:
> - `default` will no longer mean default. There is really no way around
> that.
> - Null will be treated unaccountably differently from all other values in
> switch. It becomes harder to explain how switch works -- "sorry, no null"
> is at least easy. Instead it's "well, switch *itself* allows null, but it
> assumes you want a `case null` that throws if you don't say otherwise".
> Looked at without knowing all the baggage, is this not a bit bizarre?
> - Also (back to how this email started), this appears to be the only
> factor forcing us to introduce a `default, case x` syntax we would never
> otherwise need - or to mint some other bespoke construction we would,
> again, never otherwise need.
>
> From where I sit, the cost is clearly too great compared to the benefit.
> While "never doing anything at all about this" might not be the solution, I
> am at least confident that the current proposal is not the right solution
> either, and I'd like to convince us to bench it.
>
> But again - if we can make either decision clearly, I'll be done here, and
> not even grumpy.
>
>
>
> On Fri, Apr 27, 2018 at 8:03 AM, Gavin Bierman <gavin.bierman at oracle.com>
> wrote:
>
>> I have uploaded the latest draft of the spec for JEP 325 at
>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html
>>
>> Changes from the last version:
>> * Supports new -> label form in both switch expressions and switch
>> statements
>> * Added typing rules for switch expression
>> * Restrict the type of a selector expression to not include long, double
>> and float as previously proposed
>> * Misc smaller changes from community feedback (thanks!)
>>
>> Comments welcomed!
>> Gavin
>>
>> > On 12 Apr 2018, at 22:27, Gavin Bierman <gavin.bierman at oracle.com>
>> wrote:
>> >
>> > I have uploaded a draft spec for JEP 325: Switch expressions at
>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html
>> >
>> > Note there are still three things missing:
>> >
>> > * There is no text about typing a switch expression, as this is still
>> being discussed on this list.
>> > * There is no name given for the exception raised at runtime when a
>> switch expression fails to find a matching pattern label, as this is still
>> being discussed on this list.
>> > * The spec currently permits fall through from a "case pattern:”
>> statement group into a "case pattern ->" clause. We are still working
>> through the consequences of removing this possibility.
>> >
>> > Comments welcomed!
>> > Gavin
>>
>>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com