[patterns] Nullability in patterns, and pattern-aware constructs (again)

Peter Levart peter.levart at gmail.com
Thu Jan 9 07:52:20 UTC 2020


On 1/9/20 12:13 AM, John Rose wrote:
> On Jan 8, 2020, at 12:27 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> So, summary:
>>   - the null constant pattern matches null;
>>   - "any" patterns match null;
>>   - A total type pattern is an "any" pattern;
>>   - var is just type inference;
>>   - no other patterns match null;
>>   - existing constructs retain their existing null behaviors.
> FWIW, I love this, because (a) it gives null a little niche
> at the top (case “any") and bottom (case null) of the lattice
> of patterns, and (b) it collapses two useful surface forms
> of patterns into one essential kind (“any”).
> I think, and have argued elsewhere, that although type
> inference in general risks being a confusing “action at a
> distance” phenomenon, this use of total type patterns
> is constrained enough to be easily readable in normal
> usage.  (Hint:  The total type pattern is constrained to
> be the last one.  So the type, if not “var”, is really just
> a way of documenting the switch type.)
> — John

I'm just thinking if such arrangement allows expressing all possible 
situations that may arise in a switch.

Imagine one wants to switch on (Object o) and have the following cases:

- String: case 1
- CharSequence or null: case 2
- any other: case 3

How would one structure such switch? Would case 2 have to be split 
before and after case 1?

Regards, Peter

More information about the amber-spec-experts mailing list