[patterns] Nullability in patterns, and pattern-aware constructs (again)
Peter Levart
peter.levart at gmail.com
Thu Jan 9 07:52:20 UTC 2020
Hi,
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