Re: `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 <kev...@google.com 
<mailto: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>