Simplifying switch labels
Brian Goetz
brian.goetz at oracle.com
Thu Jun 2 18:08:14 UTC 2022
> 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."
More information about the amber-spec-experts
mailing list