`case null:` (here we go)

Sun Apr 29 21:41:44 UTC 2018

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" <kevinb at google.com> 
À: "Gavin Bierman" <gavin.bierman at oracle.com> 
Cc: "amber-spec-experts" <amber-spec-experts at 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.bierman at oracle.com | gavin.bierman at 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.bierman at oracle.com | 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 | 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:kevinb at google.com | kevinb at google.com ] 

BQ_END

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