Re: Language lawyer corner: object liveness

[Sergey Zakharchenko <doublef.mobile@...>]

List,

I'm afraid I'm able to confer what I want to say to a small fraction
of people only, so I'll try to refrain from posting further on this
topic after this email. I'm not after any changes to the Lua
implementation. Rather, I propose some clarifications in the Lua
manual (which is the closest thing we have to a standard) for
consistency with "no longer accessible => OK to GC" rule (otherwise
the to-be-closed variables don't make sense at all).

Minor edit:

> A to-be-closed variable behaves like a constant local variable, except that its value is closed whenever the variable goes out of scope, including normal block termination, exiting its block by break/goto/return, or exiting by an error.

to read:

> A to-be-closed variable behaves like a constant local variable, except that its value is closed whenever the variable goes out of scope, including normal block termination, exiting its block by break/goto/return, or exiting by an error caught in the same coroutine (see 2.3 Error Handling).

Rationale: otherwise, this obviously contradicts 'Similarly, if a
coroutine ends with an error, it does not unwind its stack, so it does
not close any variable' below.

Then, and this is the main thing: after:

> Here, to close a value means to call its __close metamethod. If the value is nil, it is ignored; otherwise, if it does not have a __close metamethod, an error is raised. When calling the metamethod, the value itself is passed as the first argument and the error object (if any) is passed as a second argument; if there was no error, the second argument is nil.

add the following paragraph:

> To ensure the above guarantee of calling the value's __close metamethod, a reference to it is stored in the coroutine being run until the call is performed.

Rationale: all that I've been trying to tell you so far. No reference
means OK to GC, most likely not what we want. Dibyendu's Java sample
and Gé's C# sample are obvious because the variable is clearly visible
in scope. Not so for a Lua generic for loop closing value.

Here, we make it clear the coroutine references the value of the
to-be-closed variable, so as long as the coroutine lives, the value of
the to-be-closed variable cannot be GCd.

Minor nitpick: edit:

> If a coroutine yields inside a block and is never resumed again, the variables visible at that block will never go out of scope, and therefore they will never be closed.

to read:

> If a coroutine yields inside a block and is never resumed again, its stored to-be-closed variables will never go out of scope, and therefore they will never be closed.

Here we reuse the notion of to-be-closed variables belonging to the
coroutine, and no longer restrict the statement to variables visible
at that block only, but also to previous call stack levels (which I
believe the original intent was).

I honestly don't see how the above changes could restrict any
implementation that wouldn't be absurd without them.

Best regards,

-- 
DoubleF