Hi Kevin,
depending on the syntax constructions, in presence of null either you throw a
NPE or you have a special semantics, by example try(var x= ...) silently
doesn't call close() on null.
I do not think we can pretend that null doesn't exist, we want to be able to
switch on any objects, not just String and enums so null will show up,
what i like with the current proposal is that
- if you do not have a case null, you have a NPE which is backward compatible
- if you have a case null, it's self documented.
I also expect that most of switch where you want a case null are switch that
doesn't require a default because the compiler will be smart enough to not
requires a default.
And as you said, price to paid is that 'default' means any object but null.
Now that we have decided that the -> syntax doesn't allow fallthrough, i think
we have no choice but to allow, default has a possible 'Pattern' in the
grammar.
One interesting question is should we allow 'case default' and see 'default' as
shorter syntax for 'case default' ?
And you can also even if Brian will say No discuss about the value of the
keyword 'case', i.e. make 'case' optional everywhere.
regards,
Rémi
PS: i'm not sure that if we go back in 2004, we will change the semantics of
the switch because designing for something that may occur 14 later is not a
good idea, moreover, by going back in time we have already changed what the
future will be :)
De: "Kevin Bourrillion" <kev...@google.com>
À: "Gavin Bierman" <gavin.bier...@oracle.com>
Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
Envoyé: Vendredi 27 Avril 2018 17:59:45
Objet: `case null:` (here we go)
BQ_BEGIN
>From newest spec:
BQ_BEGIN
ClauseLabel :
BQ_END
BQ_BEGIN
BQ_BEGIN
CasePattern ->
BQ_END
BQ_END
BQ_BEGIN
CasePattern :
BQ_END
BQ_BEGIN
BQ_BEGIN
case Pattern { , Pattern }
default
BQ_END
BQ_END
BQ_BEGIN
Pattern :
BQ_END
BQ_BEGIN
BQ_BEGIN
ConstantExpression
EnumConstantName
null
BQ_END
BQ_END
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 < [
mailto:gavin.bier...@oracle.com | gavin.bier...@oracle.com ] > wrote:
BQ_BEGIN
I have uploaded the latest draft of the spec for JEP 325 at [
http://cr.openjdk.java.net/~gbierman/switch-expressions.html |
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 < [ mailto:gavin.bier...@oracle.com |
> gavin.bier...@oracle.com ] > wrote:
>
> I have uploaded a draft spec for JEP 325: Switch expressions at [
> http://cr.openjdk.java.net/~gbierman/switch-expressions.html |
> 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
BQ_END
--
Kevin Bourrillion | Java Librarian | Google, Inc. | [ mailto:kev...@google.com
| kev...@google.com ]
BQ_END
