<div dir="ltr"><div>Thanks for the feedback. Following up...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The current behavior is very easy to reason about, and 
this proposal looks too special to me.... I guess the main difference in our thinking is that I value the complexity of the JLS more.</blockquote><div><br></div><div>Yes, this definitely falls into the category of "tactical fix". It's a specific (small) fix for a specific (small) corner case.</div><div><br></div><div>You raise a good question re: whether we should be looking at a bigger picture, for example your if/then/else example. That would mean replacing "last statement of the block is V=x" with something more general.<br></div><div><br></div><div>My concern is that extending this idea in that way would necessarily be much more invasive to the spec. Instead of defining and tracking two things (DA and DU) for every possible expression, the JLS would now have to track three things: DA, DU, and "DU for the purpose of catch". Chapter 16 would expand by 50%.</div><div><div><br></div><div>So this changes the cost/benefit equation by a lot.</div><div><br></div></div><div>Or... maybe there's some simpler trick that would accomplish the same thing? If so I don't immediately see it.</div><br><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Especially because then it raises
 more questions about `Thread.stop`.</blockquote><div><br></div><div>Like what? In the source code, the catch block still can't <i>use</i> the variable, because it's still not DA. All that's changed is that it can now <i>assign</i> the variable.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also, the way 
this issue is presented is not much of a concern (at least for the 
example code). Not making the local variable final is kinda whatever.</blockquote><div><br></div><div>That's a personal preference thing. For me making variables final is important for improving code readability and I do it literally whenever possible.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Where this is annoying is when you want to capture the variable (mostly 
in a lambda). However, if that is the issue that you are trying to 
address, then I think this is the wrong solution to that issue. I think 
the real solution to the issue would be relaxing the constraint to be 
able to capture a local variable: We should be able to capture it, iff 
the variable is definitely assigned before capturing, and there is 
definitely no assignment after it.</blockquote><div><br></div><div>That's <i>not</i> the issue I'm trying to address, but I totally agree with you that it would also be a good one to have. Are you officially proposing it? If so, I support you :)<br></div></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im"><div>Would not that be addressed with the suggested switch-case-throws? See <a href="https://inside.java/2023/12/15/switch-case-effect/" target="_blank">https://inside.java/2023/12/15/switch-case-effect/</a></div></span></blockquote></div><div><br></div><div>That's a workaround, yes, but not a fix.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> This fix would just make enforcement of this rule more precise by 
modifying existing compiler rules that currently don't let through code 
that is intuitively and factually correct, but falls into a blind spot 
of specifications. ... [separate email] ... I mean, I showed a simple complication in my previous email already but let's go further. Why shouldn't the following work then?</blockquote><div><br></div><div>So to summarize what I think we can all agree on:</div><div><ul><li>In an ideal world, the compiler would perfectly/precisely identify any situation where a final variable was not assigned exactly once.</li><li>Due to the halting problem we know this is impossible. The best the JLS can do is define a reasonable approximation, and everyone understands that the rules are just an approximation.</li><li>What we have does a pretty good job but it's not perfect. It will never be perfect.</li></ul></div><div>Life is full of such situations :) In these situations we typically make incremental improvements over time, pragmatically, on a cost/benefit basis.</div><div><br></div><div>So to me the question is not "What are the <i>correct</i> rules for DA/DU" - no such rules exist - but where are there opportunities to do the normal incremental improvement thing where the cost/benefit ratio is favorable.</div><div><br></div><div>For this proposal, it's a one line JLS change. Like I said, a small fix for a small corner case.</div><div><br></div><div>I'd also support the more general version, as long as I don't have to be the one who updates Chapter 16 :)<br></div><div><br></div><div>I also think replacing the "effectively final" requirement for lambdas & inner classes to be "DA at the point of instantiation and not reassigned afterward" would be another good one, but that's a separate proposal...<br></div><div><br></div><div>-Archie<br></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>