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