`case null:` (here we go)
Kevin Bourrillion
kevinb at google.com
Tue May 1 22:38:39 UTC 2018
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>
More information about the amber-spec-experts
mailing list