<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Good point (though I'd be wary
of extrapolating too much from multicatch.)<br>
<br>
I think the discussion Aggelos was looking to stimulate is the
one that leads to a more principled understanding of when we
should and should not try to detect dead patterns. There's no
limit to what we *could* do, but we don't want to make these
decisions on the basis of "hey, we could have an error here,
cool", nor do we want to set in motion an endless whack-a-mole
of "we complain about X, and X is like Y, but we don't complain
about Y." <br>
<br>
The treatment of "domination" to detect dead cases is new with
pattern matching (previously the only dead cases where "used the
same constant twice".) So to some extent we are left
extrapolating from very little actual data. <br>
<br>
We do detect "same constant twice" even in lists: <br>
<br>
switch (i) { <br>
case 1, 2 -> ...<br>
case 2, 3 -> ... // duplicate label<br>
}<br>
<br>
But I'm not sure we want to bootstrap our way from that into
trying too hard to detect impossible cases. For example,
suppose we had range patterns: <br>
<br>
switch (i) { <br>
case 1: ...<br>
case 10: ...<br>
case 2..<=9: ...<br>
case 1..10: // dead <br>
}<br>
<br>
Would we expect the compiler to do this analysis? <br>
<br>
<br>
<br>
</font></font><br>
<div class="moz-cite-prefix">On 2/22/2023 11:07 AM, Remi Forax
wrote:<br>
</div>
<blockquote type="cite" cite="mid:577277629.27715816.1677082047731.JavaMail.zimbra@u-pem.fr">
<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" <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a><br>
<b>To: </b>"Tagir Valeev" <a class="moz-txt-link-rfc2396E" href="mailto:amaembo@gmail.com"><amaembo@gmail.com></a>,
"Angelos Bimpoudis" <a class="moz-txt-link-rfc2396E" href="mailto:angelos.bimpoudis@oracle.com"><angelos.bimpoudis@oracle.com></a><br>
<b>Cc: </b>"amber-spec-experts"
<a class="moz-txt-link-rfc2396E" href="mailto:amber-spec-experts@openjdk.java.net"><amber-spec-experts@openjdk.java.net></a><br>
<b>Sent: </b>Wednesday, February 22, 2023 4:45:38 PM<br>
<b>Subject: </b>Re: Draft JLS Spec about unnamed patterns
and variables<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"><font face="monospace">It's a tricky question,
because there's lots of ways to come at it. For
example, we do make a distinction between dead
*statements* and dead code in general, and in particular
conditionals can have lots of dead code.<br>
<br>
For example, in<br>
<br>
if (true || destroyTheWorld()) { ... }<br>
<br>
we don't remark that `destroyTheWorld()` is dead code
(though fine IDEs will call our attention with tasteful
highlighting). We're pretty aggressive about avoiding
_unreachable statements_, but considerably less
aggressive about dead code in general. <br>
<br>
Thought experiment: what if we had union type patterns?
Then the case label `case String _, Integer _` would be
like matching the the union type pattern
`(String|Integer) _`:<br>
<br>
case Number n: ...<br>
case (String|Integer) _: ...<br>
<br>
Would javac then complain that `String|Integer` could be
simplified to just `String` on the bsais of flow
analysis? (IntelliJ would, of course.) </font></font></blockquote>
<div><br>
</div>
<div>At least, the compiler complains in a try/catch, by
example<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>try {<br data-mce-bogus="1">
</div>
<div> ioCall();<br data-mce-bogus="1">
</div>
<div>} catch(IOException e) {<br>
</div>
<div> ...<br data-mce-bogus="1">
</div>
<div>} catch(FileNotFoundException | RuntimeException e) {<br data-mce-bogus="1">
</div>
<div> ... <br data-mce-bogus="1">
</div>
<div>}<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>does not compile.<br data-mce-bogus="1">
</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"><font face="monospace"><br>
I initially thought as Tagir did, but then Gavin turned
me around and reminded me that it was not dead code, but
unreachable statements that we try to avoid. So now I
am torn...<br>
</font></font></blockquote>
<div><br>
</div>
<div>Rémi<br data-mce-bogus="1">
</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"><font face="monospace"><br>
</font></font><br>
<div class="moz-cite-prefix">On 2/22/2023 10:26 AM, Tagir
Valeev wrote:<br>
</div>
<blockquote cite="mid:CAE+3fjbe1CUQN5u0xR76cJtx3zyEZ7KZjcoMWkEF08nK6OtAAQ@mail.gmail.com">
<div dir="auto">Hello!
<div dir="auto"><br>
</div>
<div dir="auto">I think we should consider dead patterns
as dead code, so this sample should not compile.</div>
<div dir="auto"><br>
</div>
<div dir="auto">With best regards,</div>
<div dir="auto">Tagir Valeev </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Feb 22, 2023,
15:34 Angelos Bimpoudis <<a href="mailto:angelos.bimpoudis@oracle.com" class="moz-txt-link-freetext" target="_blank" moz-do-not-send="true">angelos.bimpoudis@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div style="font-family:"Segoe
UI","Segoe UI ","Helvetica
Neue",sans-serif;font-size:11pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<p dir="auto" style="margin-top:0px;margin-bottom:0.7em;font-family:-apple-system,"system-ui","Segoe
WPC","Segoe
UI",system-ui,Ubuntu,"Droid
Sans",sans-serif;font-size:14px"> Coming
back to the topic of dominance for a moment
before I circulate a revised draft spec.</p>
<p dir="auto" style="margin-top:0px;margin-bottom:0.7em;font-family:-apple-system,"system-ui","Segoe
WPC","Segoe
UI",system-ui,Ubuntu,"Droid
Sans",sans-serif;font-size:14px"> Dominance
is the way of pattern matching to detect<em>dead
code</em>(meaning that code on the RHS of a
dominated case will never be executed,
provably).</p>
<p dir="auto" style="margin-top:0px;margin-bottom:0.7em;font-family:-apple-system,"system-ui","Segoe
WPC","Segoe
UI",system-ui,Ubuntu,"Droid
Sans",sans-serif;font-size:14px"> Assume
the example where<code style="font-family:"SF
Mono",Monaco,Menlo,Consolas,"Ubuntu
Mono","Liberation
Mono","DejaVu Sans
Mono","Courier
New",monospace;font-size:1em;line-height:1.357em">Number</code>dominates<code style="font-family:"SF
Mono",Monaco,Menlo,Consolas,"Ubuntu
Mono","Liberation
Mono","DejaVu Sans
Mono","Courier
New",monospace;font-size:1em;line-height:1.357em">Integer</code>--all
values of<code style="font-family:"SF
Mono",Monaco,Menlo,Consolas,"Ubuntu
Mono","Liberation
Mono","DejaVu Sans
Mono","Courier
New",monospace;font-size:1em;line-height:1.357em">Integer</code>are
going to be matched by a proceeding case,<code style="font-family:"SF
Mono",Monaco,Menlo,Consolas,"Ubuntu
Mono","Liberation
Mono","DejaVu Sans
Mono","Courier
New",monospace;font-size:1em;line-height:1.357em">Number</code>.
This is a compile-time error. Additionally
notice that all binding variables happen to be
unused.</p>
<pre dir="auto" style="margin-top:0px;padding:16px;border-radius:3px;overflow:auto;background-color:rgba(220,220,220,0.4);font-size:14px"><code style="font-family:"SF Mono",Monaco,Menlo,Consolas,"Ubuntu Mono","Liberation Mono","DejaVu Sans Mono","Courier New",monospace;font-size:1em;line-height:1.357em">switch (o) {
case Number n -> 1;
case String s -> 2;
case Integer i -> 2;
}
</code></pre>
<p dir="auto" style="margin-top:0px;margin-bottom:0.7em;font-family:-apple-system,"system-ui","Segoe
WPC","Segoe
UI",system-ui,Ubuntu,"Droid
Sans",sans-serif;font-size:14px"> Under
this JEP this code could be rewritten blindly
into:</p>
<pre dir="auto" style="margin-top:0px;padding:16px;border-radius:3px;overflow:auto;background-color:rgba(220,220,220,0.4);font-size:14px"><code style="font-family:"SF Mono",Monaco,Menlo,Consolas,"Ubuntu Mono","Liberation Mono","DejaVu Sans Mono","Courier New",monospace;font-size:1em;line-height:1.357em">switch (o) {
case Number _ -> 1;
case String _, Integer _-> 2;
}
</code></pre>
<p dir="auto" style="margin-top:0px;margin-bottom:0.7em;font-family:-apple-system,"system-ui","Segoe
WPC","Segoe
UI",system-ui,Ubuntu,"Droid
Sans",sans-serif;font-size:14px"> Under the
definition of dead code above, the common case
that was grouped together,<code style="font-family:"SF
Mono",Monaco,Menlo,Consolas,"Ubuntu
Mono","Liberation
Mono","DejaVu Sans
Mono","Courier
New",monospace;font-size:1em;line-height:1.357em">->
2</code>, is not dead anymore. It can be
reached via<code style="font-family:"SF
Mono",Monaco,Menlo,Consolas,"Ubuntu
Mono","Liberation
Mono","DejaVu Sans
Mono","Courier
New",monospace;font-size:1em;line-height:1.357em">*case
String _*, Integer _-> 2</code>. As a
result, the code above is correct. It just
happens that the sub-pattern<code style="font-family:"SF
Mono",Monaco,Menlo,Consolas,"Ubuntu
Mono","Liberation
Mono","DejaVu Sans
Mono","Courier
New",monospace;font-size:1em;line-height:1.357em">Integer
_</code>will never be reachable. This can be a
warning but the overall case is correct.</p>
<p dir="auto" style="margin-top:0px;margin-bottom:0.7em;font-family:-apple-system,"system-ui","Segoe
WPC","Segoe
UI",system-ui,Ubuntu,"Droid
Sans",sans-serif;font-size:14px"> An
alternative interpretation would be to treat
sub-patterns as "dead code". Under that
interpretation the second<code style="font-family:"SF
Mono",Monaco,Menlo,Consolas,"Ubuntu
Mono","Liberation
Mono","DejaVu Sans
Mono","Courier
New",monospace;font-size:1em;line-height:1.357em">case</code>of
the second example would be dominated because
there is at least one preceding sub-pattern (or
whole case label with one pattern as in this
case) that dominates at least one of its
sub-patterns (<code style="font-family:"SF
Mono",Monaco,Menlo,Consolas,"Ubuntu
Mono","Liberation
Mono","DejaVu Sans
Mono","Courier
New",monospace;font-size:1em;line-height:1.357em">Integer
_</code>). That case could be rejected
(symmetrically to the first example). This seems
restrictive but also a valid direction.</p>
<p dir="auto" style="margin-top:0px;margin-bottom:0.7em;font-family:-apple-system,"system-ui","Segoe
WPC","Segoe
UI",system-ui,Ubuntu,"Droid
Sans",sans-serif;font-size:14px"> So, my
question is what would be the pros and cons of
each approach?</p>
<p dir="auto" style="margin-top:0px;margin-bottom:0.7em;font-family:-apple-system,"system-ui","Segoe
WPC","Segoe
UI",system-ui,Ubuntu,"Droid
Sans",sans-serif;font-size:14px"> <br>
</p>
<p dir="auto" style="margin-top:0px;margin-bottom:0.7em;font-family:-apple-system,"system-ui","Segoe
WPC","Segoe
UI",system-ui,Ubuntu,"Droid
Sans",sans-serif;font-size:14px"> Many,
thanks,</p>
<p dir="auto" style="margin-top:0px;margin-bottom:0.7em;font-family:-apple-system,"system-ui","Segoe
WPC","Segoe
UI",system-ui,Ubuntu,"Droid
Sans",sans-serif;font-size:14px"> Aggelos</p>
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_-6873757209971852382divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b>
Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank" rel="noreferrer" class="moz-txt-link-freetext" moz-do-not-send="true">brian.goetz@oracle.com</a>><br>
<b>Sent:</b> 26 January 2023 20:33<br>
<b>To:</b> Angelos Bimpoudis <<a href="mailto:angelos.bimpoudis@oracle.com" target="_blank" rel="noreferrer" class="moz-txt-link-freetext" moz-do-not-send="true">angelos.bimpoudis@oracle.com</a>>;
amber-spec-experts <<a href="mailto:amber-spec-experts@openjdk.java.net" target="_blank" rel="noreferrer" class="moz-txt-link-freetext" moz-do-not-send="true">amber-spec-experts@openjdk.java.net</a>><br>
<b>Subject:</b> Re: Draft JLS Spec about unnamed
patterns and variables</font>
<div> </div>
</div>
<div><font size="4"><font face="monospace">Small
wording nit... in "an unnamed declaration can
be used in place of the following
declarations"<br>
<br>
I'm not sure "in place of" is the right
wording; I think you may just want to say
"in", since the grammar permits it in all of
these places. (What you're really doing here
is signalling that there are places the
grammar allows it, but the semantics do not;
you are going to call these out individually
in the appropriate places.)<br>
<br>
Similar for the second "in place of" in this
section.<br>
<br>
In 14.11.1, I might refactor the text a little
further. The second sentence of the first
paragraph below is about case constants only,
but now comes after you talk about case
patterns or case constants:<br>
<br>
</font></font>
<blockquote>
<p>A<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>label
has either one or more<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>constants,
or<del style="background-color:rgb(255,224,224);text-decoration:line-through">a</del><strong style="background-color:rgb(208,255,208);font-weight:inherit;text-decoration:underline">one
or more</strong><code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>pattern<strong style="background-color:rgb(208,255,208);font-weight:inherit;text-decoration:underline">s</strong>.
Every<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>constant
must be either (1) the<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">null</code>literal,
(2) a constant expression (<a href="https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.29" style="text-decoration:none;color:rgb(74,103,130)" target="_blank" rel="noreferrer" moz-do-not-send="true">15.29</a>),
or (3) the name of an enum constant (<a href="https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.9.1" style="text-decoration:none;color:rgb(74,103,130)" target="_blank" rel="noreferrer" moz-do-not-send="true">8.9.1</a>);
otherwise a compile-time error occurs. A<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>label
that has a<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">null</code><code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>constant
may have an optional<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">default</code>.</p>
<div>
<p style="padding:0pt;margin:0pt 0em 1ex">It
is a compile-time error if for any<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>label
with more than one<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>patterns,
any of its<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>patterns
declares one or more pattern variables.</p>
</div>
</blockquote>
<br>
I suggest:<br>
<br>
A<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>label
has either one or more<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>constants,
or<del style="background-color:rgb(255,224,224);text-decoration:line-through">a</del><strong style="background-color:rgb(208,255,208);font-weight:inherit;text-decoration:underline">one
or more</strong><code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>pattern<strong style="background-color:rgb(208,255,208);font-weight:inherit;text-decoration:underline">s</strong>.
<br>
<br>
<i>For a case label with case constants, </i>every<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>constant
must be either (1) the<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">null</code>literal,
(2) a constant expression (<a href="https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.29" style="text-decoration:none;color:rgb(74,103,130)" target="_blank" rel="noreferrer" moz-do-not-send="true">15.29</a>),
or (3) the name of an enum constant (<a href="https://docs.oracle.com/javase/specs/jls/se19/html/jls-8.html#jls-8.9.1" style="text-decoration:none;color:rgb(74,103,130)" target="_blank" rel="noreferrer" moz-do-not-send="true">8.9.1</a>);
otherwise a compile-time error occurs. A<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>label
that has a<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">null</code><code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>constant
may have an optional<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">default</code>.<br>
<br>
<i>For a case label with case patterns</i>, it is
a compile-time error if any of its<code style="white-space:pre-wrap;font-family:"DejaVu Sans Mono","Bitstream Vera Sans Mono","Luxi Mono","Courier New",monospace">case</code>patterns
declares one or more pattern variables.<br>
<br>
I am not sure about the definition of dominance
here. If I have:<br>
<br>
case Integer _, String _: A;<br>
case Number _ : B;<br>
<br>
Number dominates Integer, but it doesn't dominate
Integer|String. I think you mean "if at least one
of pi..pn dominates *all* of the patterns ri..rm,
no? <br>
<br>
But I'm not even sure if this is the right
formulation, because:<br>
<br>
sealed interface I permits A, B { }<br>
record A() implements I {}<br>
record B() implements I {}<br>
<br>
case A _, B _: ...<br>
case I i: ...<br>
<br>
The first case label dominates I. So I think you
have to appeal to exhaustiveness:<br>
<br>
"A case label with case patterns p1...pm dominates
another case label with case patterns q1...qm if
the set of patterns { p1..pm } dominates each qi",
no?<br>
<br>
You probably have to slightly refactor the second
statement about "compile time error if dominance"
accordingly.<br>
<br>
<br>
<br>
<br>
<div>On 1/26/2023 5:36 AM, Angelos Bimpoudis
wrote:<br>
</div>
<blockquote>
<div>Dear experts,</div>
<div>
<div><br>
</div>
<div>The first draft of the JLS spec about
unnamed patterns and variables (<a href="https://openjdk.org/jeps/8294349" target="_blank" rel="noreferrer" class="moz-txt-link-freetext" moz-do-not-send="true">https://openjdk.org/jeps/8294349</a>)
is available at:</div>
<div><br>
</div>
<div><a href="https://cr.openjdk.java.net/~abimpoudis/unnamed/latest/" target="_blank" rel="noreferrer" class="moz-txt-link-freetext" moz-do-not-send="true">https://cr.openjdk.java.net/~abimpoudis/unnamed/latest/</a><br data-mce-bogus="1">
</div>
<div><br>
</div>
<div>Comments very much welcomed!</div>
Angelos<br>
</div>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>