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

[Brian Goetz]

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.



On Jan 26, 2022, at 8:45 AM, forax at univ-mlv.fr<mailto:forax at univ-mlv.fr> wrote:



________________________________
From: "Brian Goetz" <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>>
To: "Remi Forax" <forax at univ-mlv.fr<mailto:forax at univ-mlv.fr>>
Cc: "Tagir Valeev" <amaembo at gmail.com<mailto:amaembo at gmail.com>>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net<mailto: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 <forax at univ-mlv.fr<mailto: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/b3b72614/attachment-0001.htm>