Explicit end-of-use: the 'forget' keyword

[Marek Kozieł]

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.

> Having references to other forums does not improve matters.

Two clarifications here:
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:
Glue classes – a more general/complex analogue of what later appeared as
extension functions in Kotlin (introduced only a couple of years later).
"Final interfaces" – effectively the simplified proposals that Java
reintroduced in 2020 as sealed types.
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.

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.

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.


> 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.
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.

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:
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.
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.



--
Greetings
Marek Kozieł ( Lasu )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260127/5ef038f8/attachment.htm>