`case null:` (here we go)

Wed May 2 16:59:47 UTC 2018

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Kevin Bourrillion" <kevinb at google.com>
> Cc: "amber-spec-experts" <amber-spec-experts at 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:kevinb at google.com |
>> kevinb at google.com ] > wrote:

>> On Tue, May 1, 2018 at 2:33 PM, John Rose < [ mailto:john.r.rose at oracle.com |
>> john.r.rose at oracle.com ] > wrote:

>>> On Apr 27, 2018, at 8:59 AM, Kevin Bourrillion < [ mailto:kevinb at google.com |
>>> kevinb at 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:kevinb at google.com |
>> kevinb at google.com ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180502/8250fe37/attachment-0001.html>