Switch labels (null again), some tweaking

[Remi Forax]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 23 Avril 2021 21:27:40
> Objet: Re: Switch labels (null again), some tweaking

> On Apr 23, 2021, at 8:38 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> ...The fact is that the natural interpretation of a total type pattern is that
>> it matches null.  People don't like this…
> 
> This person does.  As you point out, this position
> enables composition of patterns.  And composition
> is the more important goal, compared to preservation
> of intuitions about edge cases.

I agree composition is more important, a total pattern should match null because semantically a total pattern is equivalent to "else" and not "if instanceof".

[...]

>> Now, let's look back at the alternative, where we keep the flexibility of the
>> null label, but treat patterns as meaning what they mean, and letting switch
>> decide to throw based on whether there is a nullable pattern or not.  So a
>> switch with a total type pattern -- that is, `var x` or `Object x` -- will
>> accept null, and thread it into the total case (which also must be the last
>> case.)
> 
> To me this is the material point, and has been all along:
> There is never a need to perform an O(N) visual scan of
> a switch to see if it accepts nulls, since the users simply
> have to inspect the final (and perhaps initial) case of the
> the switch.  Good style will avoid puzzlers such as final
> cases which are difficult to classify (total vs. partial).
> The language does not have to carry the burden of
> enforcing full annotation.
> 
> A second point:  In the present design, and especially
> with the cleanup you are proposing, I think there are
> several possible (optionally selectable) styles of
> null processing in switches.
> 
> (Reading later I see you already brought up most
> of these points.)
> 
> Style A1 is implicit null acceptance.  Pattern
> totality determines null acceptance, end of story.
> Style A2 is implicit null rejection, with markup
> of non-totality using `default`.  That is, a coder
> could choose, as a matter of clarity, to call out
> partial final cases by adding `default: break;`
> after them.  (E-switches don’t need A2.)
> 
> Style B1 is explicit null acceptance.  If null
> is allowed by the switch, then the token
> `null` must be present, either at the head
> of the switch or just before the final total
> pattern.  Style B2 adds explicit null rejection,
> by adding something like `case null: throw …`.
> That’s probably too much noise in most cases.
> 
> The current draft mandates explicit null
> acceptance.  Brian is suggesting that we
> allow the other style too.  I think it’s a
> good suggestion.
> 
> (An extra option would be to allow some
> bespoke way to annotate totality and/or
> non-totality of the final case. 

If we have a change to do, i'm not sure, i would prefer that option.
Make clear that the last pattern is total so it matches null.

> That interacts with things like enums and sealed classes,
> so I’ll just mention it and move on.)

???,
in those cases, no total pattern is needed, i don't see the interaction.

> 
> I think that IDEs can help users pick
> the style that is correct for them.
> 
> Bottom line:  Trust the users to choose how
> explicit to be with nulls.  More importantly,
> trust them with compositional notations.

That's a solution, we do nothing and trust users.
The other solution is to force users to explicit say that the pattern is total, by example by asking to use 'var o' instead of 'Object o',
but we already discuss that and only me and Tagir were agreeing that it is a good idea.

[...]

> 
> — John

Rémi