Pattern matching: next steps after JEP 405

[Brian Goetz]

>
> Inference is also something we will need for pattern assignment
>
>   Box<>(var s) = box;

Yes, it would work the same in all pattern contexts -- instanceof as 
well.  Every pattern context has a match target whose static type is known.

>
>
>
>      - *Array patterns. * The semantics of array patterns are a pretty
>     simple extension to that of record patterns; the rules for
>     exhaustiveness, applicability, nesting, etc, are a relatively
>     light transformation of the corresponding rules for record
>     patterns.  The only new wrinkle is the ability to say "exactly N
>     elements" or "N or more elements". 
>
>
> I wonder if we should not at least work a little on patterns on 
> collections, just to be sure that the syntax and semantics of the 
> patterns on collections and patterns on arrays are not too dissimilar.

This is a big new area; collection patterns would have to be co-designed 
with collection literals, and both almost surely depend on some sort of 
type class mechanism if we want to avoid the feature being lame.  I 
don't think its realistic to wait this long, nor am I aiming at doing 
anything that looks like a generic array query mechanism.  Arrays have a 
first element, a second element, etc; the nesting semantics are very 
straightforward, and the only real question that needs additional 
support seems to be "match exactly N" or "match first N".

>
>
>
>      - *Primitive patterns. *This is driven by another existing
>     asymmetry; we can use conversions (boxing, widening) when
>     constructing records, but not when deconstructing them.  There is
>     a straightforward (and in hindsight, obvious) interpretation for
>     primitive patterns that is derived entirely from existing cast
>     conversion rules. 
>
>
> When calling a method / constructing an object, you can have several 
> overloads so you need conversions, those conversions are known at 
> compile time.
> (Note that Java has overloads mostly because there is a rift between 
> primitives and objects, if there was a common supertype, i'm not sure 
> overloads will have carried their own weights.)
>
> When doing pattern matching, there is no overloads otherwise you will 
> have to decide which conversions to do at runtime.

There are no overloads YET, because the only deconstruction patterns are 
in records, and records have only one state description.  But that is a 
short-lived state of affairs.  When we do declared deconstruction 
patterns, we will need overload selection, and it will surely need to 
dualize the existing three-phase overload selection for constructors 
(e.g., loose, string, and varargs invocation contexts.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220518/f0d4d2da/attachment.htm>