> 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 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.
