`case null:` (here we go)

[Brian Goetz]

Hearing no responses on each of these, I'm going to say we should:

  - defer case null
  - defer all new primitive targets
  - do nothing now about default placement, since all switches will 
still be constant switches in the current iteration.

These can all be deferred to the next bus full of switch improvements 
(of which there is at least one, if not two, in our near-ish future.)

On 5/2/2018 7:17 AM, Brian Goetz wrote:
> 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 <kevinb at google.com 
>> <mailto:kevinb at google.com>> wrote:
>>
>> On Tue, May 1, 2018 at 2:33 PM, John Rose <john.r.rose at oracle.com 
>> <mailto:john.r.rose at oracle.com>> wrote:
>>
>>     On Apr 27, 2018, at 8:59 AM, Kevin Bourrillion <kevinb at google.com
>>     <mailto: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. |kevinb at google.com 
>> <mailto:kevinb at google.com>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180508/aa176e18/attachment.html>