[External] : Re: Nullity (was: Pattern features for next iteration)

[Brian Goetz]

> I support making case null the only null-friendly pattern. I think I 
> advocated for this before. Special behavior for case null fallthrough 
> is not entirely ideal but looks better than case <total_pattern> 
> implicitly accepting nulls.

I think "not entirely ideal" is a good description :)

The alternative, which I think is worse (and which we've already 
discussed quite a bit), is to have both nullable and non-nullable type 
patterns.  The reason I think it is worse is that it causes users to 
have to think all the time about something that should be a corner 
case.  It is giving null too much importance.  The current proposal does 
the right thing without thinking about it 99% of the time, and with 
guards, allows you to filter out the errant null where we might have 
gotten it wrong.  (I have some other ideas along these lines that I'll 
put in a separate mail.)

> Btw while it's perfectly expected that old-style case null: are 
> executed from top to bottom, it's probably less expected that the 
> order of comma-separated labels matters. Hence, the question: will 
> `case Integer i, null -> ` be allowed? Or `null` pattern must always 
> precede anything else?

> Also, what about several type patterns, like `case null, Integer _, 
> String _ -> ... // nulls, integers, and strings but no other types go 
> here`? What about `case Integer _, null, String _ ->...`?

Right now, you can't say that, so it's not a problem :)

I think what this speaks to is that the notion of "patterns with binding 
variables" is a little fuzzy, and needs to be tightened up a bit.  
Conceptually, what you write is reasonable and seems useful, so we 
wouldn't want to foreclose on that.

Given that "case a, b, c" and "case a: case b: case c:" have no semantic 
difference now, I think we should continue with that, which suggests 
that forcing the null to come first is an arbitrary choice.  Also, I 
don't see a problem with even nontrivial fallthrough here:

      case null:
          System.out.println("nulls are annoying");
           // fallthrough
      case Object o:

I don't see any reason to outlaw this, so defining in terms of 
fallthrough is reasonable.  The weird new rule is that "if a case null 
falls into a `case T t`, t is bound to null and considered DA".