`case null:` (here we go)
guy.steele at oracle.com
Tue May 1 21:26:56 UTC 2018
“ ‘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. :-) :-)
> 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
More information about the amber-spec-experts