`case null:` (here we go)

[Guy Steele]

“ ‘case null: default:’ IS NOT FALLTHROUGH, IT’S MULTIPLE LABELS!” Guy howled into the uncaring darkness.  :-)
(I know, I know; I might as well be insisting that everybody use “whom” correctly.)

Except for that, +1.  :-)  :-)

—Guy

> On May 1, 2018, at 5: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?
> 
>> - 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