We discussed Kevin’s suggestions when Gavin and I were in Dublin this week. I think the argument for delaying some of these features for the “next bus full of switch enhancements” is pretty reasonable.
With regard to null, the argument I found most compelling is “you guys still haven’t finished designing how null will work with patterns.” Which is, I must admit, true. Given that the proximate motivation here is that patterns will essentially demand it, delivering it with patterns — when the full story is in place — seems a reasonable and prudent choice. With regard to primitives, while I think the semantics are pretty truly settled, supporting the other primitives is mostly (a) for patterns and (b) for completeness; there’s no one banging on the door for switching on floats. So while I see no strong reason to delay, I also see no strong reason to not let this one board the bus with patterns as well. (While switch on long is arguably useful, I would much rather complete the set at once than add things in bit by bit. While we have more delivery vehicles for features, it is probably best that we deliver features in coherent sets where possible.) With regard to the position of default in the switch, since we currently have nothing but constant patterns, let’s defer deciding just how hostile/accomodating we want to be to the quirks of “default”. When we have richer patterns, I don’t want to allow “default” to come ahead of cases that it dominates, but those cases can’t occur yet. So harassing users about default placement now seems premature. (As an extreme option, we might even choose to just kill default in patterns in favor of something more well-behaved. So no point expending capital on adjusting people’s use of it right now.) > On May 1, 2018, at 11:38 PM, Kevin Bourrillion <kev...@google.com> wrote: > > On Tue, May 1, 2018 at 2:33 PM, John Rose <john.r.r...@oracle.com > <mailto:john.r.r...@oracle.com>> wrote: > > On Apr 27, 2018, at 8:59 AM, Kevin Bourrillion <kev...@google.com > <mailto: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 > <mailto:kev...@google.com>
