Question about the new Exhaustiveness doc that Gavin posted

[Brian Goetz]

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(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.

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.

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.

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.

On 5/23/2023 12:56 PM, David Alayachew wrote:
> 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/cc3a5708/attachment-0001.htm>