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 <fo...@univ-mlv.fr<mailto: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.
