JEP 441: Pattern Matching for switch (suggestion re: handling sealed type selector expressions)

[Holo The Sage Wolf]

I'm not sure I understand the problem you present, are you saying that if I
have the following (I'm on my phone, so I apologize about the formatting):

sealed interface S permits A {}

switch(x) {
    case A a -> ...
    case S s -> ...
}

Then when I modify S to be:

sealed interface S permits A, B {}

My switch expression now has a hidden case? I.e. the compiler doesn't help
me know that I may want to add an explicit B case?

I can see few problems with disallowing a "catchall" clause.

Here is a textbook example of sealed types:

sealed interface Json permits JPrimitive, JArray, JObject {}

sealed interface JPrimitive<T> extends Json permits JNull, JBool, JNumber,
JString {
    T unbox();
}

// the implementation of unbox just returns the underlying object, for
JNull it returns null.
record JNull() implements JPrimitive<Void> {}
record JBool(bool val) implements JPrimitive<Boolean> {}
...

Will:

switch(x) {
    JArray a -> ...
    JObject o -> ...
    JPrimitive<?> p -> ...
}

Be allowed? It has the same problem, if we extend the permits list of
JPrimitive, the compiler won't notify you, but we really want a single
"primitive" clause, semantically we know that it won't ever change (but the
compiler has no way of knowing it).

If you only care about the "first layer", there are still cases were you
have a sealed types that permits quite a lot of types (say, 10, which is a
lot but possible), you may have a function that receive that type, and
handle 7 out of the 10 ways the same way, but 3 of the types require a
special handling (think subtypes that requires external resources, or
thread locks), not having a catchall will create a lot of boilerplate (or
will make you switch to if-else chain (pun intended))

---

If you still think it is a problem, I'm sure you could make a rule in your
linter/build pipeline to disallow catchall clauses



On Sat, Apr 8, 2023, 21:24 Robert <roberts14 at cablelink.at> wrote:

> Hi all, newbie here.
>
> First off — loving Amber features.
>
> Now, a *very narrow* observation about how JDK 20 handles sealed type
> selector expressions.
> (Code snippet below.)
>
> If a sealed type S later grows its list of permitted subtypes at some
> point,
> how should the compiler handle switch blocks with S as selector?
>
> In the absence of a catchall label (i.e. “case default -> ...” or “case S
> s -> ...”) ,
> the compiler already correctly issues an error that coverage is incomplete.
>
> But if the block ended with a catchall label, the compiler is silent; the
> best that
> can be hoped-for is that the coder throws a defensive exception in the
> catchall label
> (and hope that it is triggered in testing).
>
> Suggestion:
>
> Compiler should *disallows* catchall statements in switch blocks that use
> a sealed type
> *in the switch selector expression*.  Note that this special case does
> not affect all the
> other non-sealed-type selectors (e.g. Object o), and appears (to me) to
> strengthen the
> safety-value of sealed types in this particular scenario (similar to
> enums).
>
> All in Java’s spirit of “least surprise”.
>
> Cheers,
> Robert
>
>
> PS. reported behavior confirmed using jshell in JDK 20:
>
> jshell --enable-preview
> |  Welcome to JShell -- Version 20
> |  For an introduction type: /help intro
>
>
> on the following:
>
> sealed interface S permits S.X, S.Y, S.Z, S.NEWBIE {
>
> final class X implements S {};
>
> final class Y implements S {};
>
> final class Z implements S {};
>
> final class NEWBIE implements S {};
>
> public static void main(String [] sa) {
>
>    S something = new NEWBIE();
>    System.out.println(
> switch (something) {
> case null -> 0;
>         case X x -> 1;
>         case Y y -> 2;
>         case Z z -> 3;
> case S s -> -1;
> // case default -> -1;
> });
>     };
> }
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230409/725d1aa6/attachment-0001.htm>