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
