Observation about nulls in type patterns

[Brian Goetz]

Now we're just going in circles, we already discussed this one.  It 
creates at least as much trouble as it solves.

One problem is that while this seems like an obvious syntactic trick 
when the patterns are as simple as they are today, what happens when you 
get to deconstruction patterns?

Another is that you're kind of pretending this is a special case of an 
OR pattern, in which case you'd write it:

     case Number n | null n: ...

but now we need binding merging (which we simplified away, to everyone's 
pleasure.)  If you want to do this as a type pattern, you could 
interpret it as

     case (Number | Null) n: ...

where `Null t` is a special type pattern that only matches null; this is 
consistent with the treatment of | in catch, which is also like a 
pattern.  But this all seems pretty ad-hoc, and doesn't really help 
where we need it most, which is nesting:

      Box<String> bs;
      switch (bs) {
          case Box(var x): ...
// or
          case Box(String s): ...
      }

If this doesn't match Box(null), this will be a much bigger source of 
mistakes than this current concern.  It is pretty clear that both of the 
above want to match "all boxes", and people will routinely forget to say 
"| null" (or, be annoyed they do have to) in these cases.

If we already had a `T?` type, there'd be a natural denotation of both 
nullable and non-nullable type patterns, and this would be less 
annoying, but we don't.

So there's a reason we didn't pick this one the first time around.


(Stepping back, I would remind you that we are in the classic trap of, 
after having considered the problem in entirety, trying to fix the 
things we don't like locally, without re-doing the global analysis, just 
becomes someone noticed one of the things we don't like for the first time?)


On 7/27/2020 5:05 PM, Remi Forax wrote:
>
> Instead of having an idiom, we can use a restricted Java-ish syntax.
> For me it's a lot like when you want a serializable lambda and you end 
> up with an ad hoc java-ish syntax (Foo & Serializable) s -> ...
>
> So i propose Number | null,
>   switch (o.get1().get2()) {
>     case Integer i -> ...
>     case Number | null n -> …
>   }
>
> it's a restricted syntax too, it's either "type | null" and it's 
> obviously explicit, it also makes the rule that say if a switch accept 
> null or not more obvious because it's decouple from the notion of a 
> total coverage, if a case accept null then the switch accept null.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200727/a616494b/attachment-0001.htm>