<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello Brian,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you for your response!</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Special thanks for the link to the doc especially. That was illuminating.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">That said, it does provide an opportunity to move the goal posts even further.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">In your doc, we introduce the concept of P to represent the set of patterns. We then apply that set of patterns to various parts of the target (for records, its components, because, like the doc said - if you match the components, you match the record). Essentially, the doc says that it takes the set of patterns, looks at the target to see "what needs to be matched in order to be exhaustive", and then starts matching.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">But that's the point -- it can tell you when certain parts don't match. So what if we just constrained ourselves down to just that? Just telling the user that a specific part doesn't match?<br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Using your example from above, what if we moved the goal posts even further and just said something like the second component on the record has not been fully covered? It doesn't have to tell us what to fill that hole with -- it just needs to tell us that there is a hole there.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you for the help!</div><div class="gmail_default" style="font-family:monospace">David Alayachew<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 31, 2024 at 6:11 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@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"><u></u>
<div>
<font size="4" face="monospace">I think you are probably thinking
about this in too few dimensions. For a one-dimensional problem:<br>
<br>
sealed interface X permits A, B, C { }<br>
<br>
switch (x) { <br>
case A a -> <br>
case B b -> ...<br>
}<br>
<br>
it seems quite easy to "find the missing case." But here's an
only slightly harder one:<br>
<br>
sealed interface A permits T, U { }<br>
sealed interface B permits V, W { }<br>
record R(A a, B b) { } <br>
<br>
switch (r) { <br>
case R(A a, V b) -> ... <br>
case R(T a, _) -> ... <br>
}<br>
<br>
What's missing? Well, there are any number of cases that can
complete the picture, such as<br>
<br>
case R(U a, W b) -> ... <br>
<br>
The problem gets harder fast as the dimensionality increases; R
has two components, both of which use sealing. And things scale
with not only the number of components, but the depth of sealed
hierarchies, etc. <br>
<br>
If you read the specification (or the precursor mathematical
model, an early version of which is here
(<a href="https://cr.openjdk.org/~briangoetz/eg-attachments/Coverage.pdf" target="_blank">https://cr.openjdk.org/~briangoetz/eg-attachments/Coverage.pdf</a>),
you'll see that it does not construct the full product space and
start "checking off boxes", so turning it into an example
generator (and keeping the two consistent) is not a small task. <br>
<br>
</font><br>
<div>On 1/30/2024 10:55 PM, David Alayachew
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div style="font-family:monospace">Hello
Tagir,</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">Thank
you for your response!</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">Fair
point about NP-Complete. Maybe scaling back the idea would
make more sense.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">But I
am confused about this comment.<br>
</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">>
From what I remember, it could be very non-trivial to
determine a minimal set of missing branches
</div>
<br>
<div style="font-family:monospace">I'm
very surprised to hear this, but if that is true, then let's
scale this down to the absolute minimum.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">In
order to know that we are missing a case, we must first find a
gap in the exhaustiveness, with respect to the remainder.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">So
let's move the goal posts and say that if we can report that
single type that is the gap, I would be happy enough with
that.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">Would
that be more realistic?</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">Thank
you for reaching out!</div>
<div style="font-family:monospace">David
Alayachew<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jan 30, 2024 at
3:21 AM Tagir Valeev <<a href="mailto:amaembo@gmail.com" target="_blank">amaembo@gmail.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">
<div dir="ltr">IntelliJ IDEA can do this in simple cases (use
'Create missing branches' action in Alt+Enter menu on
"statement does not cover all possible input values" error
message). From what I remember, it could be very non-trivial
to determine a minimal set of missing branches in a general
case, especially if you have generic parameters and nested
deconstruction patterns. I'm not sure but probably it's an
NP-complete problem.
<div><br>
</div>
<div>With best regards,</div>
<div>Tagir Valeev.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jan 30, 2024 at
6:40 AM David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.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">
<div dir="ltr">
<div style="font-family:monospace">Hello
Amber Dev Team,</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">The
previous discussions on Checked Exceptions reminded me
about this.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">Is
there any possible future where sealed types will be
able to tell you which permitted subtypes are missing?</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">This
is actually one of the sleeper features of Checked
Exceptions -- they don't just give you exhaustiveness,
they are even nice enough to tell you exactly which
Exception type you left out.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">This
is a godsend for maintenance, fearless refactoring,
and general correctness.</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">Any
chance we could get this for sealed types in the
future?</div>
<div style="font-family:monospace"><br>
</div>
<div style="font-family:monospace">Thank
you for your time and help!</div>
<div style="font-family:monospace">David
Alayachew<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div>