Two new draft pattern matching JEPs
Brian Goetz
brian.goetz at oracle.com
Sat Mar 6 17:51:34 UTC 2021
> The “as” pattern which binds a value before doing
> more pattern matching
Note that for all the patterns we have right now, there is no need: type
patterns, record/deconstruction patterns, and array patterns all take an
identifier (optional in the last two) which is the as-slot. I believe
users will find:
case Point(var x, var y) p:
much more natural than
case Point(var x, var y) & var p:
and, additionally, if we intend to generalize local declaration / method
parameters to support total patterns, then we will want this extra
syntax anyway:
void m(Point(var x, var y) p) // p is surely required here
So the "as" slot right now is a theoretical concern, but, your point is
taken, that a conjoined `var` pattern can act as an "as".
> on it should can be synthesized
> from “var” and “&”, as “P & var x”. The rules for
> inferring “var” types should take into account
> left context as much as possible; I don’t think
> that’s all there yet. (I think “var x & P” is a
> novice’s error, since the inferred type is poor.)
I think what you're saying is that if P has a target-type of T, and Q
has a target-type of U, then in
x instanceof (P & Q & var x)
and, given x : X, then, since we won't even try to match `var x` unless
P and Q already match, we seed inference with constraints x <: X, x <:
T, and X <: U, and will generally get out (some normalization of) x <:
T&U&X.
> You noted that array patterns sometimes want to
> refer into the middle of the array.
I think this is relatively low on the priority list; matching the whole
array, or an initial segment of the array, seem natural use cases for
the language, but I'm not sure I want to embed a comprehension-query
language to pick up the rest of the use cases.
> If and when we do special construction expression syntax
> for list, map, set, and 99 other user-defined types (I’m
> serious about the 99; that’s a lower limit) then we will
> want to make associated pattern syntaxes available.
> The array stuff is a harbinger of this, since (as is rightly
> so) the construction syntax new int[]{stuff} is associated
> with the deconstruction syntax which is exactly the
> same, except (a) the “new” is gone, and (b) the “stuff”
> is pattern-land instead of expression-land.
The array syntax is closely related to declared patterns with varargs
(of which varargs records are already on the docket.)
> You mention constraints that force switches to be
> either pattern switches or non-pattern switches.
> (This is near the example with “error1”.)
This was intended as a transitional ("Preview 1") simplification. A
constant case `case L` can be desugared to `case var x && x == L`
relatively easy.
> For a non-pattern switch, you conservatively
> left out “case null,1,2,3:”. I think that’s too
> conservative. I won’t always want to route
> null to the default case.
Yep, good catch.
More information about the amber-spec-experts
mailing list