Re: Yet another proposal for <toclose> (was Re: [ANN] Lua 5.4.0 (alpha) now available)

[Dibyendu Majumdar <mobile@...>]

On Thu, 27 Jun 2019 at 22:55, Sean Conner <sean@conman.org> wrote:
>
> It was thus said that the Great Dirk Laurie once stated:
> >
> > I've been a Lua user for almost ten years, and I've succeeded in
> > understanding and sometimes using every language addition in that
> > time. Not so with <toclose>.
> >
> > My perceptions about it are:
> >
> > 1. It solves a problem encountered by a very small fraction of Lua users.
> > 2. Although it looks like a property of a variable, i.e. a name, it is
> > a property of the associated value.
> > 3. All variables declared <toclose> must have a metatable with a
> > __close metamethod, otherwise nothing different happens anyway.
> > 4. Therefore they must be either tables or full userdata.
> > 5. The 5.4 alpha syntax for it is the least ugly among various
> > possibilities, but still ugly.
> > 6. It runs counter to Lua's design goals of being minimal, neat and compact.
> >
> > In other words, <toclose> is feature bloat.
>
>   Reading this, I just had an idea.
>           scope f,err = io.open("foobar")


I think that handling multiple return values elegantly requires
specific names to be declared as to-be-closed.

Given the issues with finding a good syntax for it - maybe we can live
with the proposed <toclose> syntax.

Alternatively, and this is an idea proposed by Daurnimator, and one I
think perhaps will be a better solution is to introduce the 'defer'
statement like the Go language.
Interestingly the Go language also supports multiple return values and
uses idioms similar to Lua where an error value is returned as
additional parameter.

The proposed 'defer' statement looks like this:

defer ... end

Where it is simply a synonym for:

local f = function()  ... end

with the guarantee that f will be invoked at scope exit.

This has several nice properties.

1) It is more generic
2) The syntax is nice
3) It is explicit and visible
4) One can perform any kind of cleanup - not just closing resources
5) Variables may be captured as upvalues in the function too


Regards
Dibyendu