<div dir="ltr">Thanks for the explanation!<div><br></div><div>I filed <a href="https://bugs.openjdk.org/browse/JDK-8349857">https://bugs.openjdk.org/browse/JDK-8349857</a> to record this.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2025 at 3:41 AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm not sure the capture is the issue here. Note that if the case is <br>
rewritten to<br>
<br>
case B b<br>
<br>
Then everything works as expected and javac doesn't get confused by <br>
capture conversion. Note that capture conversion is always problematic <br>
when it comes to cast expressions -- because the cast has to "relax" <br>
some of the captured variable that might be introduced by capture <br>
conversion. This is an area of the specification that is underspecified, <br>
so javac (and other implementations) have to workaround such issues the <br>
best they can.<br>
<br>
The particular example you pose seems like it should work to me -- <br>
there's only one possible parameterization for A<T> coming up from B.C - <br>
and that's A<String>, so the conversion should be safe here. It seems to <br>
me like a case of bad interplay between enums constants and patterns.<br>
<br>
Maurizio<br>
<br>
<br>
On 28/01/2025 18:51, Liam Miller-Cushon wrote:<br>
> Hi,<br>
><br>
> Chris Povirk and I were trying to understand why examples like the <br>
> following are rejected:<br>
><br>
> sealed interface A<T> {<br>
>   enum B implements A<String> {<br>
>     C;<br>
>   }<br>
><br>
>   static void d(A<?> a) {<br>
>     switch (a) {<br>
>       case B.C:<br>
>     }<br>
>   }<br>
> }<br>
><br>
> A.java:8: error: incompatible types: B cannot be converted to A<CAP#1><br>
>       case B.C:<br>
>             ^<br>
>   where CAP#1 is a fresh type-variable:<br>
>     CAP#1 extends Object from capture of ?<br>
><br>
> I think this is a consequence of JLS 6.5.6.1, which says that the type <br>
> of the switch selector expression is subject to capture conversion, <br>
> and then the captured type is not convertible.<br>
><br>
> In the implementation, this is happening here [1], where attribExpr <br>
> uses KindSelector.VAL, which causes the capture to happen.<br>
><br>
> Has consideration been given to treating selector expressions <br>
> differently, to avoid the capture conversion, and allow examples like <br>
> this to compile? I couldn't find test coverage for this specific <br>
> combination of features, which made me wonder if this was a corner <br>
> case that hadn't been explored, rather than something that had <br>
> definitely been ruled out.<br>
><br>
> Liam<br>
><br>
> [1] <br>
> <a href="https://github.com/openjdk/jdk/blob/a224f12cb701b45df4706a403a05c66de2d623af/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1702" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/blob/a224f12cb701b45df4706a403a05c66de2d623af/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1702</a><br>
</blockquote></div>