Knocking off two more vestiges of legacy switch

[forax at univ-mlv.fr]

> From: "Dan Heidinga" <heidinga at redhat.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "John Rose" <john.r.rose at oracle.com>, "Brian Goetz"
> <brian.goetz at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Tuesday, September 13, 2022 8:42:23 PM
> Subject: Re: Knocking off two more vestiges of legacy switch

> <snip>

>> So my main concern stay that
>> String s = ...
>> switch(s) {
>> case Comparable<?> c -> ... //Dan: matches here as String implements Comparable
>> (this case is total on "s" so no further matching)
>> case Object o -> ...
>> }

>> and
>> long l = ...
>> switch(l) {
>> case float f -> ... //Dan: matches here if l is convertable to a float
>> case double d -> ... //Dan: otherwise matches here
>> }

>> behave differently.

> In each case, we're finding the switch case that the value is compatible with.
> Another way to say it is the value is convertable to... or castable to. Can you
> expand on what you mean by "behave differently"?

In the first example, both type patterns are total so it does not compile because both patterns will match all Strings. 
In the second example, if we follow the semantics proposed by Brian, the first pattern is partial and is equivalent to iff (l == (long) (float) l) { float f = l; ... } and the second pattern is total. 

> I'm still working on reading through the "big picture" presentation in [0] so if
> there's a particular section there that you think is relevant, I can re-read
> that first. It might be useful for both of us to re-read it and see how this
> example fits with the bigger picture being proposed for pattern matching.

This document give you a nice overview of the problems but some parts are outdated, the following spec correspond to the semantics for Java 19 
https://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-15.28 

The proposed semantics of the primitive pattern is described here 
https://mail.openjdk.org/pipermail/amber-spec-experts/2022-September/003497.html 
and here 
https://mail.openjdk.org/pipermail/amber-spec-experts/2022-September/003499.html 

> --Dan

> [0] [
> https://openjdk.org/projects/amber/design-notes/patterns/pattern-match-object-model
> |
> https://openjdk.org/projects/amber/design-notes/patterns/pattern-match-object-model
> ]

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