`case null:` (here we go)

[Kevin Bourrillion]

On Tue, May 1, 2018 at 2:33 PM, John Rose <john.r.rose at oracle.com> wrote:

On Apr 27, 2018, at 8:59 AM, Kevin Bourrillion <kevinb at google.com> wrote:
> >
> > 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.
>
> You have to push the historic hostility to null either to the switch or
> the default.  So either (as you say) "default doesn't mean default"
> or (with the same meaning) "switch doesn't mean switch" or we
> break history or we ret-con either switch or default.  Pick your poison.
> I pick "default means (null-hostile) default".  What's so hard about that?
>

We can't just localize the null-hostility to `default`, since
null-case-less switches that don't have `default` will still throw.

It has always been `switch` itself that is null-hostile. We can only change
that through conceptual contortions; I'm doubtful we can find anything as
tidy as what you suggest.


> - 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.
>
> It's not easy at all when you *need* to pass nulls.


Sure. I was making a different point about the conceptual simplicity of the
feature. "Easy to explain" and "easy to code your use case" are simply
different topics.


I don't buy the objection
> that we didn't allow nulls before; now we will allow "case var x:" and
> (again) the choice is simple and stark:  either "var means var" (and
> allows null if the type is nullable) or else "var means null-hostile var"
> in a switch.  Really, you are plumping for "switch is (null-hostile)
> switch", but that has the unfortunate effect of making "var" be null
> hostile in a switch—


Would that really look like a null-hostile `var`? To me, it looks like the
var allows null but the switch is not letting it through. If I doubt that,
I can just look at the stack trace. I assume it would point straight at the
switch, as it does today.


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

> A bit.  Far less bizarre than "Here's a general classifier syntax.
> But it doesn't work on null, sorry."


I suppose we'll agree to disagree on this part. I think it's unfortunate,
but still conceptually simple. The reason it rejects null is the exact
same reason it always did. (The fact that reason is *bad* was already
conceded at top.)



> > - 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.
>
> We don't need to mint any such construction.  We could simply say this:
> "You know that old fallthrough thing you sometimes need for combining
> cases?  Well, you need need it when you want case null to fall through
> into default."  Null-friendliness, in that story, is just one of the
> factors
> that might move you towards colons and away from arrows.
>
> And Remi has already sketched a reasonable extension (bespoke
> construction) which is good for lots of things:  You simply give an
> "or" construction along the lines of "case x,y,z:" and then you allow
> default to play in the or construction.  There's nothing surprising
> about that proposal, when you realize that the main use of
> fall-through in today's switches is to get the effect of an or
> construction, with or without default.  What's more natural
> than finding a way to do this with arrow-switches?  You don't
> even need to mention null to justify this, and then easier null
> friendliness (with arrow as well as colon) is one of the side-effects.
>

This sounds like a persuasive case that the grammar should allow for
`default, case null`. But I agree with that already (it was how this thread
began). It is fine. I just felt it was noteworthy that we would never have
needed the ability to comma-combine default with other case labels if not
for this. It's minted for this very special case.

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180501/b1818b9e/attachment.html>