Primitives in instanceof and patterns

forax at univ-mlv.fr forax at univ-mlv.fr
Sat Sep 10 08:57:50 UTC 2022


> 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: Friday, September 9, 2022 10:12:21 PM
> Subject: Re: Primitives in instanceof and patterns

> I have a question about your example. I'm not trying to be clever and play
> "whatabout", I'm looking for a straight answer why you think the two cases are
> different.

>> If we take a simple example
>> record Point(int x, int y) { }
>> Point point = ...
>> switch(point) {
>> case Point(int i, int j) -> ...
>> ...
>> }

>> let say know that we change Point to use longs
>> record Point(long x, long y) { }

>> With the semantics you propose, the code still compile but the pattern is now
>> transformed to a partial pattern that will not match all Points but only the
>> ones with x and y in between Integer.MIN_VALUE and Integer.MAX_VALUE.

> The same is true when I start with

> record Foo(String s) { ... }

> and later change it to

> record Foo(Object s) { ... }

> (both are incompatible changes, but we won't dwell on that.)

> My question is: why does it not bother you that use-site patterns like
> `Foo(String s)` are reinterpreted as partial after the String -> Object change,
> but the analogous change with long -> int bothers you so much that you'd use it
> to argue against being able to ask whether a long is also an int?

> You obviously think that these two examples are radically different. Can you
> explain why? Is it anything more than "that's the way its always been"?

I think i've been a little over my head with this example. 

I've forgotten that in both cases, the patterns move from being a total pattern to be a partial pattern so the enclosing switch will not be exhaustive anymore, thus not compile. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20220910/0ac6676d/attachment.htm>


More information about the amber-spec-experts mailing list