[External] : Re: Primitive type patterns

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Thursday, April 7, 2022 11:24:05 PM
> Subject: Re: [External] : Re: Primitive type patterns

>> We already discussed those rules when we discuss instanceof, it means that "x
>> instanceof primitive" has different meaning depending on the type of x

> No, it does not. It means "does x match the pattern P" everywhere. It is pattern
> P is that has different meanings depending on type. This may sound like a silly
> distinction, but it is not! Pattern matching is inherently polymorphic -- it is
> all about reflecting dynamic conversions statically -- and exhibits the *same*
> polymorphism regardless of where it occurs.
The switch is (runtime) polymorphic while each patterns does not have to be (statically) polymorphic. 
If you prefer, i'm okay with be a pattern overriding polymorphic but not with a pattern being overloading polymorphic (sometimes called ad-hoc polymorphism). 
Your are proposing overloading of patterns, i.e the same pattern having different meaning depending on the static types. 

> And, why would we not want duality with:

> record R(short s) { }
> ...
> new R(x)
because new R(x) is alone while case R(...) is part of a larger set of patterns/sub-pattern of the pattern matching, if for each pattern/sub-pattern, we need a double-entry table to understand the semantics, we are well past our complexity budget. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220407/c4a58aae/attachment-0001.htm>