Feedback on nulls in switch

[Remi Forax]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Stephen Colebourne" <scolebourne at joda.org>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Mardi 11 Août 2020 02:42:50
> Objet: Re: Feedback on nulls in switch

> On Aug 10, 2020, at 4:03 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
>> 
>> Given:
>>  box instanceof Object o
>> o is non-null. And given:
>>  switch (box) {
>>     case Box b:
>>  }
>> b is non-null.
> 
> That latter is not necessarily true and I think you need a better example.
> 
> The b can be null because the case is the last case and therefore (not
> otherwise) may be total. When I see the last case in a switch I expect it to be
> a catch-all, don’t you?  Here it depends on the type of box up in the switch
> header. I suppose it’s a Box. So that last case catches whatever the previous
> zero cases did t catch.
> 
> If Box b = box; is valid, and it sure looks that way, then that last case is
> indeed a catch all. And in that case, unless we enact a specific anti I’ll
> policy, any and all nulls will flow through that point.
> 
> I think we all are going to have to learn to read the bottom of a switch as a
> probable catch-all.
> 
> Maybe we want to add a modifier to enforce the assumption, and exclude the
> implicit default; I’ve suggested ‘final case’ as a cite bikeshed color. There
> are many others.

if you have a modifier, you don't need the pattern to be total because the user is already saying that this case is null friendly.
And having a modifier, is IMO just another syntax to my Object|null proposal.

I think being the last type pattern is enough.

> 
> None of that eases your discomfort with null flows. But it does undercut your
> claims of illegibility.

Rémi