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

[Brian Goetz]

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).  The proposed change to top-level null hostility doesn’t affect that.

So I’m not sure what your objection is?

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/5d7be9ca/attachment-0001.htm>