Observation about nulls in type patterns

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Guy Steele" <guy.steele at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 28 Juillet 2020 01:07:20
> Objet: Re: Observation about nulls in type patterns

>> When you have a design issue where half of the planet think one way
>> and half of the planet think the other way,
>> the best is to have a kind of "mother may i" rule, basically, you ask
>> the user to explicitly refine its intent.
> 
> But I don't think it is half and half.  If you show people
> 
>     switch (o) {
>         case Foo(var x, var y, var z): ...
>     }
> 
> and ask them "will this match all Foos", 999 out of 1000 will say "of
> course, what else could it do?"   The idea that this might fail if z
> happened to be null would not occur to anyone.

Null also means it doesn't exist for a lot of people, so obviously, it doesn't match.

Anyway, that's not the problem, the problem here is that the semantics depend if the pattern is total or not and if you ask people does this pattern is total or not, you will not get a 1 per 1000 ratio of right answers.

> 
> The semantics we've proposed stem from the above observation, plus the
> requirement that `var` mean type inference, and not something more
> subtle.  If you are saying `var`, you should be able to substitute it
> for the sensibly inferred type (if it is denotable) and get the same
> semantics.  This is not a random "gee, maybe this works."

I don't disagree, the problem is more than it's easy as a human to think that a pattern is total while it's not (and vice-versa) and the proposed rule is also prone to action at distance issues.

> 
> Where things are troubling are not the pattern semantics, but how it
> interacts with `switch`.  So, if you think the status quo is
> unacceptable, any "fix" needs to be closer to the switch interaction.

I don't disagree with the analysis of the problem, as you said, the problem is not new.
But a solution based on the fact that people will compute that a pattern is total or not is not pragmatic.

At least the C# solution is pragmatic, the rule is not pretty because the meaning of var inside a switch is not the same as outside a switch but at least you have a syntactic marker of how a pattern will interact with null.

As i said the other solution i see is to be more explicit,
  switch (o) {
    case Foo(var|null x, var|null y, var|null z) -> ...
  }
but it supposes that people don't like to have nullable components.

Rémi