Re: [NoW] Once more about to-be-closed variables

[Jonathan Goble <jcgoble3@...>]

On Wed, Jul 3, 2019 at 2:19 AM Sean Conner <sean@conman.org> wrote:
>
> It was thus said that the Great Egor Skriptunoff once stated:
> >
> > IMO, "to-be-closed variable accidental assignment alert" should be moved
> > from Lua core into external software (such as luacheck)
> > Besides, it would be useful to have non-constant to-be-closed variables
>
>   So, what exactly should happen in this code?
>
>         local <toclose> f = io.open("a")
>         local x = f
>         f = io.open("b") -- should 'a' be closed?  or not because of x
>         f = io.open("c") -- should 'b' be closed?
>
>   -spc (Trying to pin down semantics here ... )

Here's an idea for syntax:

local f = <toclose> io.open("a")

Instead of the variable being marked for closing, the object is
marked. Then there is no confusion over what happens if the object is
assigned to another variable or a different object is assigned to the
same variable, because the variable itself no longer cares whether it
is marked or not.

Of course, you need some definition of an object going out of scope.
Reference counting easily solves that and can be implemented in a way
that only counts references for to-be-closed objects so that the usual
case (not to-be-closed) isn't slowed down. The INCREF and DECREF calls
that are pervasive in Python C extensions aren't an issue in Lua C
extensions, since Lua doesn't allow objects to be held in arbitrary C
variables and so the counting can be handled behind the scenes (add a
reference when adding to the stack, subtract a reference when popping
from the stack). The only issue I can see would be figuring out how to
determine the initial reference count when first marking an object.