Pattern matching: next steps after JEP 405

forax at forax at
Thu May 19 07:21:13 UTC 2022

> From: "Brian Goetz" <brian.goetz at>
> To: "Remi Forax" <forax at>
> Cc: "amber-spec-experts" <amber-spec-experts at>
> Sent: Wednesday, May 18, 2022 11:08:41 PM
> Subject: Re: Pattern matching: next steps after JEP 405

>>> - 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.)
When you have a type pattern X in a middle of a pattern *and* you have conversions, then there is an ambiguity, 
does instanceof Box(X x) means 
Box(var v) && v instanceof X x 
Box(var v) && X x = (X) v; 

For the deconstruction pattern, if we have overloads, there is the same kind of ambiguity 
does Box(X x) means 
calling Box.deconstructor(X) 
calling Box.deconstructor(Y) with y instanceof X 

So if we want to support overloads, and we may have to, at least to support adding components but keeping the class backward compatible, we need to introduce new rules to solve that ambiguity. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list