Re: Question about pattern matching and sealed types – redundant switch cases

[Brian Goetz]

This doesn't really have as much to do with sealed types or pattern 
matching as it might seem; it has to do with to what degree the language 
is willing to engage in flow-based type analysis.

The short answer is: there's not a lot of appetite for investing in 
this.  The cost and complexity is likely high both initially and 
ongoing, and the impact on program correctness is fairly marginal.  (The 
simple cases are easy, but just handling the simple cases is a recipe 
for an infinite stream of enhancement requests.)

If we're going to invest at all in flow-based type analysis, we'd likely 
start with nullity analysis.  This is a simpler problem (and still, not 
simple) and probably would have more impact.

On 4/19/2025 12:17 PM, Andreas Berheim Brudin wrote:
> Hi all,
>
> I'm new to the list—apologies if this has been discussed before, and 
> thanks in advance for your time.
>
> I have a question about pattern matching with sealed types. Consider 
> this example:
>
> sealed interface A permits B, C {}
> record B(String b1, String b2) implements A {}
> record C(String c) implements A {}
>
> A myVar = ...;
> if (!(myVar instanceof B(var b1, var b2))) {
>     return switch (myVar) {
>         case C(var c) -> c;
>         case B b -> throw new IllegalStateException("should not happen");
>     };
> }
> // use b1, b2
>
> Here, I want to keep an early-return style, but since I need to return 
> a value from C, I have to use a switch. This leads to redundancy: 
> we've already tested myVar is not a B, so that case should be 
> statically unreachable.
>
> My questions:
>
> 1. Is there any consideration or ongoing work to allow the compiler to 
> automatically eliminate such unreachable cases?
>
> 2. If only one case remains (in this case, C), could it be possible to 
> treat the variable as a C directly without requiring an explicit switch?
>
> Again, apologies if this has already been discussed. I'd appreciate 
> any pointers to relevant threads or JEPs if so.
>
> Thanks,
> Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250419/23e20d05/attachment.htm>