case null vs null pattern

[Brian Goetz]

This is correct; I agree this is “not quite where we want to be yet”, but the path to get there is not obvious, which is why we haven’t proposed anything more than we have.  

At some level (though this isn’t the whole story), the “null pattern” is in the same limbo as constant patterns.  Constant case labels are currently still just case labels, not patterns, so you can say `case 1` but cannot yet say `case Foo(1)`.  The semantics of constant patterns are trivial, but we’re still not sure what the best way to surface it is.  (This is mostly a syntax bike shed, but I don’t want to paint it now.)   So when constant patterns come to the top of the priority list, null will be waiting there along with “foo” and 42.  

Still, that doesn’t get us out of the woods; we can express “Foo or null” with a binding in switches, but not in instanceof.  (Truly, null is the gift that keeps on giving.)  Maybe the way out of that is nullable type patterns (`T?`), but we’re not ready to go there yet either.  

In the meantime, nulls in switch can avail themselves of the same workaround that other constant patterns do: `case Foo(var x) when x == null`.  

> On Apr 16, 2022, at 8:57 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi all,
> i maybe wrong but it seems that the spec consider null as a kind of case instead of as a kind of pattern, which disables the refactoring that should be possible with the introduction of the record pattern.
> 
> Let suppose i have a sealed type with only one implementation declared like this
> 
>  sealed interface I {
>    record A() implements I { }
>  }
> 
> if null is part of the set of possible values, i have switches like this
> 
>  switch(i) {
>    case null, A a -> // do something with 'a' here
>  }
> 
> 
> Now we are introducing record pattern into the mix, so i can have a Box of I,
>  record Box(I i) { }
> 
> the problem is that i can not write
>  switch(box) {
>    case Box(A|null a) -> // do something with 'a' here
>  }
> 
> because null is handled as a kind of case instead of as a kind of a null pattern.
> 
> Should we introduce a null pattern instead of having a specific "case null" ?
> (and disallow the null pattern in an instanceof ?)
> 
> regards,
> Rémi