You can say you only change the semantics of switch not the semantics
of pattern matching, but the idea that you can separate the two is
confusing.
From a mathematical point of view, it is quite clear. We define a `x
matches P` relation. In this relation, `Object o` matches all values of
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Tagir Valeev" , "amber-spec-experts"
>
> Sent: Thursday, January 27, 2022 4:41:27 PM
> Subject: Re: [External] : Re: Treatment of total patterns (was: Reviewing
> feedback on patterns in switch)
>> In that case, i prefer the current semantics
In that case, i prefer the current semantics because it's the same if a pattern
is a top-level or not.
I wish people could keep these things straight. We’re not talking about
changing the semantics of how pattern matching works, which patterns match
what, what nesting means, etc. We’re
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Tagir Valeev" , "amber-spec-experts"
>
> Sent: Wednesday, January 26, 2022 3:08:39 PM
> Subject: Re: [External] : Re: Treatment of total patterns (was: Reviewing
> feedback on patterns in switch)
> I don’t think its helpful to try and reopen
I don’t think its helpful to try and reopen these old and settled issues. I
get that you think null should have a larger syntactic presence in the
language, and you’ve made those points plenty of times, but we’re not reopening
whether `Object o` is total, or whether `var` is more than type
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Tagir Valeev" , "amber-spec-experts"
>
> Sent: Wednesday, January 26, 2022 1:47:38 PM
> Subject: Re: [External] : Re: Treatment of total patterns (was: Reviewing
> feedback on patterns in switch)
> Heh, you are incrementally rediscovering exactly
Heh, you are incrementally rediscovering exactly why we chose the original
“total is total” rule; of all the possible treatments, it is the most logically
consistent. Welcome.
In this case, however, switches must be total. So here, either D is total
(perhaps with remainder), or B/C/D cover
> I strongly support this change.
>
> In my experience, it's much more important to have automatic
> refactorings between switch and chains of 'if' than between nested and
> flat switches.
Of course, this might be partially because we *have* chains of if else now, but
no switches on nested