On Tue, May 1, 2018 at 2: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? > We can't just localize the null-hostility to `default`, since null-case-less switches that don't have `default` will still throw. It has always been `switch` itself that is null-hostile. We can only change that through conceptual contortions; I'm doubtful we can find anything as tidy as what you suggest. > - 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. Sure. I was making a different point about the conceptual simplicity of the feature. "Easy to explain" and "easy to code your use case" are simply different topics. 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— Would that really look like a null-hostile `var`? To me, it looks like the var allows null but the switch is not letting it through. If I doubt that, I can just look at the stack trace. I assume it would point straight at the switch, as it does today. > 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 suppose we'll agree to disagree on this part. I think it's unfortunate, but still conceptually simple. The reason it rejects null is the exact same reason it always did. (The fact that reason is *bad* was already conceded at top.) > > - 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. > This sounds like a persuasive case that the grammar should allow for `default, case null`. But I agree with that already (it was how this thread began). It is fine. I just felt it was noteworthy that we would never have needed the ability to comma-combine default with other case labels if not for this. It's minted for this very special case. -- Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
