> From: "Dan Heidinga" <[email protected]>
> To: "Remi Forax" <[email protected]>
> Cc: "John Rose" <[email protected]>, "Brian Goetz"
> <[email protected]>, "amber-spec-experts"
> <[email protected]>
> 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
