<div dir="ltr"><div>The "try-with-resources" is ubiquitous, and makes the code cleaner (and in fact better due to `addSuppressed`). While this feature would end up with a Checkstyle feature developed to disallow this (and I would turn on such a rule). This is because this feature is to help bad code stay bad for longer. The feature has no security benefit (despite you alluding to it), because if people want to add a line that would end up being a security issue, then "forget" will not stop them, because one, they can remove it, second they can place their code before the forget (most likely). They will not skip doing that, because they already thought it out that this is what they want, and "forget" does not imply that anything is insecure after (a comment is way more likely to stop something bad).</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Marek Kozieł <<a href="mailto:develop4lasu@gmail.com">develop4lasu@gmail.com</a>> ezt írta (időpont: 2026. jan. 27., K, 8:35):<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">To sum up, I fully agree that this is an extremely niche feature. For me it sits just above try-with-resources: not something you use everywhere, but when it fits, it removes a class of problems quite effectively. I’ve tried to point that out explicitly in the post.<br><br>> Having references to other forums does not improve matters.<br><br>Two clarifications here:<br>Project Coin was a place for proposing language changes, but in practice most of the "chosen" features were those already prepared and feasible in the time frame. For many other proposals there was only brief, time boxed discussion, and we were explicitly asked to stop sending additional ideas. The fact that something didn’t make it into that one release does not mean it was thoroughly evaluated and rejected on principle. We’ve since seen:<br>Glue classes – a more general/complex analogue of what later appeared as extension functions in Kotlin (introduced only a couple of years later).<br>"Final interfaces" – effectively the simplified proposals that Java reintroduced in 2020 as sealed types.<br>So there is precedent for ideas discussed back then being dropped for schedule/complexity reasons, then reappearing later. I reference those discussions to show continuity of thought, not as an argument from authority.<br><br>Reddit references I included mainly to reduce repeated questions and give readers a place to see prior objections and clarifications, not as proof that the idea is good.<br><br>I’ve been looking for areas where this idea would be especially useful, and it’s entirely possible that such areas are rare — or that people are simply not used to focusing on this kind of problem.<br><br><br>> I'd kick this back to the author to gain experience in writing with the idioms and the spirit of the language as using block scope is a basic skill.<br>That’s exactly why this concept is here: over the years I’ve found cases where relying only on block scope or refactoring was not ideal in practice.<br><br>The "classic" example you mention is already in the post: you start with simple code, then later add validation, normalization, or security constraints. But when bug happen then choice often becomes:<br>do a total refactor (new methods, extra scopes, renamed variables, more surface area), or do fix without any safeguard against misusing the old variables -  this can mean a difference of days.<br>In real projects, especially under time pressure, people very often choose the second option. "forget" keeps diffs small, preserves history, and still gives a hard safety guarantee - without introducing additional risks.<br><br><br> <br>--<br>Greetings<br>Marek Kozieł ( Lasu )</div>
</blockquote></div></div>