<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">While I understand the
motivation for this request, I think the answer is that you
don't really want this. In the toy examples, it is easy to say
"the remainder is Box(null)", and think it might be desirable to
handle that case explicitly. In the real-world examples, you
get exponential explosions when patterns have more than one
nested pattern, and the error-checking cases could easily
overwhelm your real cases. And, what are you going to do
differentially between Box(null, Box(x)) and Box(</font></font><font size="4"><font face="monospace">Box(x), null)? They're both "null
where I didn't expect one." And even if you could statically
handle all the null remainders, what about the novel enum
constants / novel sealed class subtypes? No one is actually
going to write this code, so investing in having the compiler
validate it seems a poor investment. <br>
<br>
In any case, I think you're looking at the feature backwards; it
is a feature, not a bug, that you don't have to explicitly
handle cases that are structurally unrealistic. <br>
<br>
In some future world (which I'm not ready to talk about, so
please sit on the obvious "ooh, tell me more about this"
questions), you may be able to explicitly use nullability
markers in patterns (e.g., Foo(String! s)), but this doesn't
materially change the story about remainder, it just gives you a
chance to be more explicit and concise about what you mean.
Explicitly nullable patterns (e.g., `Box? b`) may be able to
override the null-hostility of switch, just as `case null` does
today. <br>
<br>
In summary, I don't think that the feature you propose is the
right place to try to be more picky about nulls; it has a lot of
cost and complexity for little incremental expressive power. <br>
</font></font><br>
<div class="moz-cite-prefix">On 5/23/2023 12:56 PM, David Alayachew
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA9v-_Nnd5o=bh-bx68j+frnXvm9x1-ms0+__so2-tP=bL5ctA@mail.gmail.com">
<div dir="ltr">
<div style="font-family:monospace" class="gmail_default">Hello
Amber Dev Team,<br>
<br>
I saw the new exhaustiveness doc by Gavin Bierman and Brian
Goetz.<br>
<br>
<a href="https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/exhaustiveness.md" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/exhaustiveness.md</a><br>
<br>
I think this is an incredibly valuable doc that points out
some extremely subtle cavities that null (as well as
unexpected runtime types/values) can snake its way into. And
while the doc did an excellent job of highlighting the rules
necessary for methodically addressing all of the "remainders",
it really just reaffirmed to me that null is toxic and that I
should avoid it wherever possible.<br>
<br>
But of course, I can't always do that, and worse yet, I might
be on codebases where null is not only returned, but is
considered a valid, acceptable response. So much so that I am
expected to respond to null with something other than a
failure case - again, some codebases treated it as a valid
value that you should use in your business logic.<br>
<br>
In those scenarios, the null-hostility of switch actually
hurts me more than it helps. If I have
Box<Box<String>>, and I need different behaviour
if the inner box is null, I won't get any notification of that
in the exhaustiveness check example that you all provided.
Now, I don't think that that is a bug or an issue with how
pattern-matching for switch currently is. But that does lead
me to a question.<br>
<br>
Is there a future where we might get some (opt-in) warning if
we haven't addressed every null "remainder" in the
exhaustiveness check? I would not wish this behaviour to be on
by default (I wouldn't wish that on my worst enemy), but as an
opt-in option, for those of us who swim in a sea of nulls?<br>
<br>
Thank you for your time and help!<br>
David Alayachew<br>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>