Question about the new Exhaustiveness doc that Gavin posted

[David Alayachew]

Hello Amber Dev Team,

I saw the new exhaustiveness doc by Gavin Bierman and Brian Goetz.

https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/exhaustiveness.md

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.

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.

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.

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?

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230523/ac227204/attachment.htm>