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 <fo...@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

Reply via email to