`case null:` (here we go)
Kevin Bourrillion
kevinb at google.com
Fri Apr 27 15:59:45 UTC 2018
>From newest spec:
*ClauseLabel*:
*CasePattern ->*
*CasePattern:*
*case Pattern { , Pattern }*
*default*
*Pattern:*
*ConstantExpression*
*EnumConstantName*
*null*
Just a reminder that we still have this conflict to resolve. Even when you
learn the wart that `default` is not covering null, there is no way to
*make* it do so without repeating the RHS. We need `default, case null:`.
Of course, my preferred resolution is to *hold off* on `case null` support
for now. I'd like to give one honest attempt at a full argument; I hope to
get an engaged response to it, and then if a decision is made against it,
I'll move on, figure I was wrong, and never speak of it again. :-)
~~
1. For the sake of argument I'll just concede the notion that today's null
behavior in switch was a mistake and if we could turn back time we would
change it.
2. On the flip side, I think that proponents of the feature can probably
concede that we would *never* have designed it in the now-proposed way for
a fresh language; it *is* a permanent wart brought about by historical
accident only. (Yes?) So, I assume that proponents recognize that rejecting
this change is at least *defensible*, by appealing to the compatibility
constraints we inherited. We should not need to worry that we will "look
like idiots" (or whatever terms our deepest fears phrase themselves in :-)).
3. Many users since 2004 have said, and will continue to say, that they
wish `case null` were allowed. However, I don't think we can assume they
are necessarily comparing today's behavior to the *actual* feature we are
proposing, with its warts. It is likely and natural that they are really
comparing today's behavior to the time-machine feature of our having
supported `case null` from the start. Therefore I think we have to take
most such requests with a grain of salt.
4. Yes, sometimes users do write code that simulates `case null` and that
code could be nicely simplified if null were allowed in switch. I can do a
better job of quantifying the incidence of this need in our large codebase if
necessary (but have been prioritizing string literal research for now). But
fundamentally, the feature *is* a win, for *these* examples.
5. It has been implied that patterns are what make the current null
treatment "untenable". To me, I don't think this argument has been made
convincingly yet. It seems to add up to "there may be a few more of those
cases where you bump up against the prohibition and think 'oh yeah, grrrr,
can't switch directly on null because of reasons no one understands!'" But
fundamentally it seems like the same problem it already was.
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.
- 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. 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?
- 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.
>From where I sit, the cost is clearly too great compared to the benefit.
While "never doing anything at all about this" might not be the solution, I
am at least confident that the current proposal is not the right solution
either, and I'd like to convince us to bench it.
But again - if we can make either decision clearly, I'll be done here, and
not even grumpy.
On Fri, Apr 27, 2018 at 8:03 AM, Gavin Bierman <gavin.bierman at oracle.com>
wrote:
> I have uploaded the latest draft of the spec for JEP 325 at
> http://cr.openjdk.java.net/~gbierman/switch-expressions.html
>
> Changes from the last version:
> * Supports new -> label form in both switch expressions and switch
> statements
> * Added typing rules for switch expression
> * Restrict the type of a selector expression to not include long, double
> and float as previously proposed
> * Misc smaller changes from community feedback (thanks!)
>
> Comments welcomed!
> Gavin
>
> > On 12 Apr 2018, at 22:27, Gavin Bierman <gavin.bierman at oracle.com>
> wrote:
> >
> > I have uploaded a draft spec for JEP 325: Switch expressions at
> http://cr.openjdk.java.net/~gbierman/switch-expressions.html
> >
> > Note there are still three things missing:
> >
> > * There is no text about typing a switch expression, as this is still
> being discussed on this list.
> > * There is no name given for the exception raised at runtime when a
> switch expression fails to find a matching pattern label, as this is still
> being discussed on this list.
> > * The spec currently permits fall through from a "case pattern:”
> statement group into a "case pattern ->" clause. We are still working
> through the consequences of removing this possibility.
> >
> > Comments welcomed!
> > Gavin
>
>
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
More information about the amber-spec-observers
mailing list