Question about the new Exhaustiveness doc that Gavin posted

[David Alayachew]

Hello Brian,

Thank you for your response!

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

Ironically enough, your box null is a great example of a bug I had in early
May. Box(Box(x), null) is a valid value for my situation, but Box(null,
Box(x)) is an invalid value. We were treating both as valid (because I am
in a sea of nulls). I have a few more stories I can point to.

To address your quote in full, you are correct, I don't really want this.
After all, the thing I ask for is essentially a band-aid or a warning sign.
Nobody really wants a band-aid, they really want to heal the wound, and a
band-aid facilitates healing. But the band-aid itself is constricting,
uncomfortable, and gets in the way of everything I want to do. I wear it
because it stops the bleeding - out of necessity. Not because there is
anything else inherently desirable about one.

And yes, I am very much aware of the combinatorial explosion drowning my
valid use cases. Unfortunately, if my valid use cases fall under any of
those null remainders, then that safety net might (understandably) lead me
away from null, and thus, from covering my valid use cases. You'd be
surprised by just how many of my valid use cases actually exist underneath
the safety net that you all have provided.

But I think your last sentence makes a decent point. Me and the few others
who have it this bad are a very tiny minority in the gigantic sea of Java
developers. If the benefit this feature provides only helps such a small
subset of developers, then fair enough, I can accept that the feature might
not be worth adding at all.

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

Oh, I don't consider this to be a bug at all. I even said as much in my
original comment. This functionality you all have provided is a good and
sensible default. I said as much in my original comment. You all made the
correct choice having things this way, and I don't want to change that.

My original comment was asking if we could opt-in to the combinatorial
explosion mode via a warning. Like I said, I wouldn't wish this on anyone
as a default, you all got it right the first time. I just wanted to make
switch a bit more helpful for my particular use case. And either way, your
next quote addresses this point too.

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

Oh cool. And yes, guilty as charged, that was going to be my next question.

But yes, if that ever comes my way, then that would be a great solution for
my dilemma. An even better one than I described in fact. This solution
allows me to isolate this behaviour to just the switch expression that I
apply it to, and not my whole codebase. I much prefer this strategy to the
one I suggested.

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

If you are saying that the return on investment is not enough to justify
doing this, then fair enough. Plus, you have already presented a possible
alternate solution that (if it happens) would address my problem much more
effectively. That definitely satisfies my question.

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/37fb5931/attachment.htm>