[External] : Re: Primitive type patterns

[Brian Goetz]

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