“ ‘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.r...@oracle.com> wrote: > > On Apr 27, 2018, at 8:59 AM, Kevin Bourrillion <kev...@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
