> From: "Brian Goetz" <brian.go...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Tagir Valeev" <amae...@gmail.com>, "amber-spec-experts" > <amber-spec-experts@openjdk.java.net> > 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 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 inference. We’re > focused here on the interaction between switch and patterns, precisely because > switch comes to the table with pre-existing null hostilities. We are not going > to distort the semantics of pattern matching just so we can extrapolate from > how C switch worked; we’ve been over this too many times. In that case, i prefer the current semantics because it's the same if a pattern is a top-level or not. Rémi >> On Jan 26, 2022, at 8:45 AM, [ mailto:fo...@univ-mlv.fr | >> fo...@univ-mlv.fr ] wrote: >>> From: "Brian Goetz" < [ mailto:brian.go...@oracle.com | >>> brian.go...@oracle.com ] >>> > >>> To: "Remi Forax" < [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] > >>> Cc: "Tagir Valeev" < [ mailto:amae...@gmail.com | amae...@gmail.com ] >, >>> "amber-spec-experts" < [ mailto:amber-spec-experts@openjdk.java.net | >>> amber-spec-experts@openjdk.java.net ] > >>> 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 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 whatever the content of Box is, or >>> it >>> doesn’’t compile. If there is remainder (which is likely to be null, but >>> which >>> won’t happen with a type pattern, only when D is more complicated), and no >>> later case handles Box(null), then the switch will NPE. We don’t know if >>> Box(null) is matched by any of these cases, but we *do* know that we will >>> not >>> arrive at the statement after the switch if the target was Box(null). >> It's true that if you can observe the different side effects when the code is >> run, and from that you may have an idea if case Box(D d) matches or not (and >> prey that there is not a catch() in the middle), >> but the bar is very low if you say that to understand a code you have to run >> it. >>> The proposed change to top-level null hostility doesn’t affect that. >> yes, that my point, having to run a code to understand it is a clue that the >> semantics you propose or the Java 18 one are both equally bad. >> Again, the C# semantics does not have such problem, if we suppose that the >> code >> compiles then with the code below, d can not be null >> switch(box) { >> case Box(B b) -> { } >> case Box(C c) -> { } >> case Box(D d) -> { } // does not accept null >> } >> while with this code, d can be null >> switch(box) { >> case Box(B b) -> { } >> case Box(C c) -> { } >> case Box(var d) -> { } // accept null >> } >> Rémi >>>> On Jan 26, 2022, at 2:53 AM, Remi Forax < [ mailto:fo...@univ-mlv.fr | >>>> fo...@univ-mlv.fr ] > wrote: >>>> We should go a step further, this also means that with >>>> switch(box) { >>>> case Box(B b) -> {} >>>> case Box(C c) -> {} >>>> case Box(D d) -> {} >>>> } >>>> we have no idea if the switch will accept Box(null) or not. >>>> So the idea that a type behave differently if nested inside a pattern or >>>> not is >>>> not a good one.
