[External] : Re: Primitive type patterns
Brian Goetz
brian.goetz at oracle.com
Mon Feb 28 14:34:02 UTC 2022
>
> 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.)
Let me try explaining the latter one more time, because you really do
seem to have a deep misundestanding of the semantics being proposed, and
until we can clear that up, I'm not sure there's much point in arguing
about the finer points.
> if (o instanceof Circle(Point(int x, int y), int radius))
> means
... doesn't match ...
> while
> Circle(Point(int x, int y), int radius) = c;
> means
... throws ...
> In the context of switch or instanceof, a pattern does not have to be
> total, while in case of a assignment the pattern has to be total,
> so depending on the context, the semantics is different.
No, this is still incorrect. The semantics of the *pattern match* does
not change. Ever. Period. The pattern Circle(Point(int x, int y), int
radius) does not match `new Circle(null, 3)`, ever. Ever. EVER. Got
it? It DOES NOT MATCH. Pattern matching is 1000% consistent on this
point. What you've observed is a statement about instanceof vs switch
vs let, not about pattern matching at all.
What is different is that we have different constructs (instanceof,
switch, let, try--catch, etc) which use pattern matching. One
(instanceof) evaluates to false when the operand is null (it doesn't
even try testing the pattern), and doesn't require the pattern to be
(statically) exhaustive, because it is a boolean expression. Let, on
the other hand, requires the pattern to be exhaustive, but tests the
pattern anyway, and if it does not match, throws (just like switch
throws on null when there is no null case.)
The difference here is entirely "when does the construct decide to try
to match" (e.g., switch can throw NPE before trying to match any cases
if it likes) and "what does the construct do when it runs out of
patterns to try" (instanceof says false, switch and let throw,
try...catch would eventually allow the exception to propagate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220228/30d71f19/attachment.htm>
More information about the amber-spec-experts
mailing list