`case null:` (here we go)

[John Rose]

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?

> - 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.  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—which will be so surprising (we think) that we
need to figure out a way to move the null-hostility out of the switch
header, and into the default.

> 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'm trying to see it your way,
but I still think the best trade-off is putting the historical baggage
on default, not at the top of the switch.

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

— John