> 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: 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
