Some thoughts about the recent discussion on Member Patterns.

[Red IO]

Some thoughts on your concerns.

On Fri, Apr 5, 2024, 03:20 David Alayachew <davidalayachew at gmail.com> wrote:

> 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 don't see how it would be leaky. Adding a case pattern to a class
would/should be considered a braking change to the class same as adding a
new type to a sealed types hierarchy. Causing compile errors on every
previously exhaustive pattern match.


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

There is a need for objects to be distinguishable in different states
without being split in different types. As much as I love type driven
design it isn't the only case for pattern matching. Especially with things
like value classes that are fundamentally incompatible with identity based
type matching of sealed types. Also old classes that expose constructors
can't be turned into a sealed hierarchy without braking api changes. But
changing a class from 0 to X case patterns isn't a braking change similar
to the addition of generics in the past.


> * 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/
>

Great regards
RedIODev

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240405/8f13606f/attachment.htm>