> From: "Brian Goetz" <brian.go...@oracle.com>
> To: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> 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 
or 
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) 
or 
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. 

RĂ©mi 

Reply via email to