<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"Andreas Berheim Brudin" <andreas.brudin@gmail.com>, "amber-dev" <amber-dev@openjdk.org><br><b>Sent: </b>Saturday, April 19, 2025 6:59:57 PM<br><b>Subject: </b>Re: Question about pattern matching and sealed types – redundant switch cases<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4" face="monospace">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. <br><br>
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.) <br><br>
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. </font></blockquote><div><br></div><div>This is also because we may restrict nullity analysis to only a type-checking pass that has no impact on the generated code while general flow typing change the generated code by changing method selection, inserting casts or instanceof + throw so adding such analysis after the fact is more disruptive.</div><div><br data-mce-bogus="1"></div><div>regards,</div><div>Rémi</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4" face="monospace"><br></font><br>
<div class="moz-cite-prefix">On 4/19/2025 12:17 PM, Andreas Berheim
Brudin wrote:<br>
</div>
<blockquote cite="mid:CAKJ_Mj717vW8yeYi7etZvniibRzCuamu58vN7HpkKUZ5oUSo2A@mail.gmail.com">
<div dir="ltr">
<div>Hi all,<br>
<br>
I'm new to the list—apologies if this has been discussed
before, and thanks in advance for your time.<br>
<br>
I have a question about pattern matching with sealed types.
Consider this example:<br>
<br>
sealed interface A permits B, C {}<br>
record B(String b1, String b2) implements A {}<br>
record C(String c) implements A {}<br>
<br>
A myVar = ...;<br>
if (!(myVar instanceof B(var b1, var b2))) {<br>
return switch (myVar) {<br>
case C(var c) -> c;<br>
case B b -> throw new IllegalStateException("should
not happen");<br>
};<br>
}<br>
// use b1, b2<br>
<br>
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.<br>
<br>
My questions:<br>
<br>
1. Is there any consideration or ongoing work to allow the
compiler to automatically eliminate such unreachable cases?<br>
<br>
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?<br>
<br>
Again, apologies if this has already been discussed. I'd
appreciate any pointers to relevant threads or JEPs if so.<br>
<br>
Thanks,<br>
</div>
Andreas</div>
</blockquote>
<br><br></blockquote></div></div></body></html>