----- Original Message ----- > From: "Brian Goetz" <brian.go...@oracle.com> > To: "daniel smith" <daniel.sm...@oracle.com>, "amber-spec-experts" > <amber-spec-experts@openjdk.java.net> > Sent: Thursday, June 2, 2022 8:08:14 PM > Subject: Re: Simplifying switch labels
>> In this framing, the restrictions about sets of elements in a single label >> don't >> apply, because we're talking about two different labels. But we have rules to >> prevent various abuses. Examples: >> >> case 23: case Pattern: // illegal before and now, due to fallthrough Pattern >> rule > > Ideally, the fallthrough rule should be about _bindings_, not > _patterns_. If P an Q are patterns with no binding variables, then it > should be OK to say: > > case P: > case Q: > > The rule about fallthrough is to prevent falling into code where the > bindings are not DA. > >> Note that the second kind of Pattern SwitchLabel is especially weird—it binds >> 'null' to a pattern variable, and requires the pattern to be a (possibly >> parenthesized) type pattern. So it's nice to break it out as its own >> syntactic >> case. I'd also suggest rethinking whether "case null," is the right way to >> express the two kinds of nullable SwitchLabels, but anyway now it's really >> clear that they are special. > > This is a painful compromise. While this may be a transitional > phenomena, the rule "switch matches null only when `null` appears in a > case" is a helpful way to transition people away from "switch always > throws on null." It also allows to express that a switch statement on an enum should be exhaustive by adding case null -> throw null; Rémi