> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Kevin Bourrillion" <kev...@google.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Mercredi 2 Mai 2018 13:17:58 > Objet: Re: `case null:` (here we go)
> 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. I wonder if there are not 3 steps: 1/ the expression switch 2/ the switch on new kinds any type, long, handling of null 3/ the full pattern matching that can do match, extract, backtrack, match, extract, backtrack, etc I've separated 2 and 3 because the translation strategy is very different depending if you can do extraction or not, technically, it's if you can do matching on extracted data that change the translation. > 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. yes > 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.) ok > 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.) yes, we can still replace default by '_' with another semantics. Rémi >> On May 1, 2018, at 11:38 PM, Kevin Bourrillion < [ mailto:kev...@google.com | >> kev...@google.com ] > wrote: >> On Tue, May 1, 2018 at 2:33 PM, John Rose < [ mailto:john.r.r...@oracle.com | >> john.r.r...@oracle.com ] > wrote: >>> On Apr 27, 2018, at 8:59 AM, Kevin Bourrillion < [ mailto:kev...@google.com >>> | >>> 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. | [ >> mailto:kev...@google.com | >> kev...@google.com ]
