[External] : Re: Treatment of total patterns (was: Reviewing feedback on patterns in switch)

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Tagir Valeev" <amaembo at gmail.com>, "amber-spec-experts"
> <amber-spec-experts at 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:forax at univ-mlv.fr |
>> forax at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220126/b0f62e80/attachment.htm>