Some thoughts about the recent discussion on Member Patterns.

[David Alayachew]

Hello Amber Dev Team,

I wanted to chime into the recent discussion about Member Patterns, but on
a side topic. I decided to make this a separate thread to avoid distracting
from the main discussion.

In that discussion, I saw Brian Goetz make the following claim.

> ## Exhaustiveness
>
> There is one last syntax question in front of us: how to
> indicate that a set of patterns are (claimed to be)
> exhaustive on a given match candidate type.  We see this
> with `Optional::of` and `Optional::empty`; it would be
> sad if the compiler did not realize that these two
> patterns together were exhaustive on `Optional`. This is
> not a feature that will be used often, but not having it
> at all will be repeated irritant.
>
> The best I've come up with is to call these `case`
> patterns, where a set of `case` patterns for a given
> match candidate type in a given class are asserted to be
> an exhaustive set:
>
> ```
> class Optional<T> {
>     static<T> Optional<T> of(T t) { ... }
>     static<T> Optional<T> empty() { ... }
>
>     static<T> case pattern of(T t) for Optional<T> { ... }
>     static<T> case pattern empty() for Optional<T> { ... }
> }
> ```
>
> Because they may not be truly exhaustive, `switch`
> constructs will have to back up the static assumption of
> exhaustiveness with a dynamic check, as we do for other
> sets of exhaustive patterns that may have remainder.
>
> I've experimented with variants of `sealed` but it felt
> more forced, so this is the best I've come up with.

Later on, I saw Clement Charlin make the following response.

> # Exhaustiveness
>
> The `case` modifier is fine, but the design should leave
> room for `case LABEL` or `case (LABEL1, LABEL2)` to
> delineate membership in exhaustive set(s), as a potential
> future enhancement.

To be explicit, I am assuming that we will eventually be able to
exhaustively deconstruct Optional using something like the following.

switch (someOptional)
{

    case null               -> System.out.println("The Optional itself is
null?!");
    case Optional.of(var a) -> System.out.println("Here is " + a);
    case Optional.empty()   -> System.out.println("There's nothing here");

    //no default clause needed because this is exhaustive

}

Once pattern-matching lands for normal classes, Optional is almost
guaranteed to be the class most frequently deconstructed/pattern-matched.
And since it does not use sealed types, it will really push a lot of people
to model exhaustiveness as a set of methods.

It's kind of frustrating.

One article that captures my frustration well is from Alexis King --
"Parse, don't Validate" [1].

In it, she talks about the value of parsing data into a container object,
with the intent of capturing and RETAINING validation via the type name.

String validEmailAddress vs record ValidEmailAddress(String email) {/**
Validation logic in the canonical constructor. */}

The moment that the String validEmailAddress leaves the local scope where
the validation occurred, its validation is no longer known except through
tracing. But having a full-blown type allows you to assert that the
validation has already been done, with no possible chance for misuse or
mistakes.

I guess my question is, in what instances would we say that modeling a set
of patterns rather than a set of types would be better? The only argument
that I can think of is conciseness. Or maybe we don't want to poison our
type hierarchy with an edge case scenario. That point specifically seems to
be the logic that Optional is following.

My hesitation comes from the fact that pattern sets feel a little leaky.
And leaky gives me distress when talking about exhaustiveness checking.

With sealed types, if I want to implement SomeSealedInterface, I **MUST**
acknowledge the question of exhaustiveness. There's no way for me to avoid
it. My implementing type MUST be sealed, final, or non-final. And even if I
implement/extend one of the implementing types of SomeSealedInterface, they
either propogate the question, or they opt-out of exhaustiveness checking.
Bullet proof!

But adding a pattern to a class does not carry the same guarantee. If I add
a new pattern that SHOULD have been part of the exhaustive set, but isn't,
I have introduced a bug. This same bug is NOT POSSIBLE with sealed types.
Hence, leaky.

I guess my thoughts could be summed up as the following -- I feel like we
are making an escape-hatch for Optional that I don't think would be worth
the weight if there was any other way for Optional to be exhaustive. And if
that is truly true, does that REALLY justify doing this? Feels tacked onto
the side and leaky imo.

And I will close by saying, I actually used to think this was a good idea.
I have said so on multiple occasions on this exact mailing list. But the
more that I think about it, the more that I see no real good reason to do
this other than "Optional needs it".

* Conciseness? Not a strong argument. Conciseness should be used to
communicate a semantic difference, not just to shorten code. Think if
statements vs ternary expressions.

* Semantic difference? Barely, and not in a way that isn't otherwise
possible. It's just when clauses with exhaustiveness attached tbh. You're
better off modeling it explicitly. Again, Parse, don't validate.

Thank you all for your time and help!
David Alayachew

[1] = https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240404/162e7d7a/attachment.htm>