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

[Attila Kelemen]

I think, if we want to find a problem to solve (already kinda starts bad),
then that example is not really the best, because either I can see that it
is the last use, if for some reason, this is a complicated method, then you
can likely refactor the subsequent part into a separate method to make it
cleaner. That is, in that example, the "forget" or "last use" (or whatever
alternative name it would go by) is just trying to save on code cleanup
(not the best thing to promote imho).

If we need a problem to be solved, then it is usually because you have a
parameter which you normalize, and now people should not use the old one.
That is, you want to shade the old variable. I don't think "forget" is a
good way to address this problem. And normally, you can still factor out
the last part into a separate method easily.

Archie Cobbs <archie.cobbs at gmail.com> ezt írta (időpont: 2026. jan. 27., K,
17:32):

> I feel the need to push back a little bit against the idea-bashing here...
>
> I completely agree that adding a new "forget" keyword to the Java language
> doesn't meet the required cost/benefit standard.
>
> However that's a separate criticism from the underlying goal, which I like
> - i.e., help simplify the mental accounting that developers must juggle in
> their heads.
>
> If I am looking at a method that starts like this:
>
> void method() {
>
>     // Grab a highly sensitive object
>     final NuclearLaunchButton btn = NuclearLaunchButton.instance();
>     ...
>
>     // Do other stuff...
>     ...
> }
>
> It would be nice to know as soon as possible when "btn" is no longer going
> to be used in that method.
>
> So this is a perfectly appropriate task for IDE's or static code checkers,
> e.g.:
>
> void method() {
>
>     // Grab a highly sensitive object
>     final NuclearLaunchButton btn = NuclearLaunchButton.instance();
>
>     // Check status
>     final boolean armed = btn.isArmed();    // *@last-use(btn)*
>
>     // Do other stuff...
> }
>
> -Archie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260127/bfe45a00/attachment-0001.htm>