[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: Saturday, February 26, 2022 5:49:08 PM
> Subject: Re: [External] : Re: Primitive type patterns

>>> #### Relationship with assignment context

>> That's a huge leap, let's take a step back.

>> I see two questions that should be answered first.
>> 1) do we really want pattern in case of assignment/declaration to support
>> assignment conversions ?
>> 2) do we want patterns used by the switch or instanceof to follow the exact same
>> rules as patterns used in assignment/declaration ?

[...] 

>> 2) we already know that depending on the context (inside a switch, inside a
>> instanceof, inside an assignment) the rules for pattern are not exactly the
>> same.

>> So we may consider that in the assignment context, assignment conversions apply
>> while for a matching context, simpler rules apply.

> We could of course say that; we could say that `int x` is simply *not
> applicable* to a target of type Integer. We can discuss that, but I don't think
> its a simplification, though; I think its actually *more* complexity because
> it's yet another context with yet another subtly different set of rules. One
> obvious consequence of that restriction would be that users cannot refactor

> Foo f = e

> to

> let Foo f = e

> to

> if (e instanceof Foo f) { ... }

> for yet more accidental reasons. Is this really making things simpler?

>> Then the model you propose is too clever for me, the fact that
>> instanceof Point(double x, double y)
>> has a different meaning depending if Point is declared like
>> record Point(double x, double y) { }
>> or like this
>> record Point(Double x, Double y) { }
>> is too much.

> If this is your concern, then I think you are objecting to something much more
> fundamental than the semantics of primitive patterns; you're objecting to the
> concept of nesting partial patterns entirely.
Nope, 
i'm saying that inside a pattern if we let the unboxing to be possible with the semantics that if the value is null, instead of throwing a NPE if it does not match, we are introducing the equivalent of the null-safe operator of Groovy (the elvis operator), something we should not do (and that was rejected in the past, i think as part of Coin or Coin 2). 

let A(B(C c)) = a else null; 
is equivalent to 
var result = a.?getB().?getC(); 

Maybe it means that we should allow unboxing with the semantics that it throw a NPE i.e the exact semantics of the assignment conversion instead of disallowing unboxing as i proposed, I don't know, but I really dislike the semantics you are proposing here. 

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