> 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: Monday, February 28, 2022 3:34:02 PM
> Subject: Re: [External] : Re: Primitive type patterns
>> 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).
> Too silly to respond to. Let's stay serious, please.
>> 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.
> It seems more likely that you just *don't understand* what is being proposed
> here (and the fact that you keep repeating the incorrect claim that pattern
> matching somehow means different things in different constructs underscores
> that.)
[....]
It's your view of the world you think that you can subsume all pattern usages
by saying that they obey to the assignment conversions and you think you can
decompose the unboxing as nullcheck + do not match.
I believe that you are wrong on both counts, the former results in an
over-generalization that will transfer part of the work the compiler does at
compile time at runtime and the later means you are choosing in place of the
user if it means Integer(int value) or Integer instead of asking.
Given that the first point subsumes the second one, i think we should focus on
it, first.
So with
record Atom(Object o) { ... }
Atom box = ...;
if (o instanceof Atom(byte b)) {
}
can box = new Atom(3); matches the pattern at runtime ?
Rémi
