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

[Sean Conner <sean@...>]

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.  It introduces just one new keyword,
removes annotations entirely, and (I think?) introduces just a *bit* of
cognitive overload.

	do
	  -- --------------------------------------------------------------
	  -- 'scope' is like 'local' in that the variable is local to the
	  -- current scope, but unlike 'local', the variable is closed at
	  -- the end.  When we leave the current scope, each variable
	  -- declared as a 'scope' is checked for a __close metamethod, and
	  -- if it exists, it is called; otherwise, nothing happens.
	  -- --------------------------------------------------------------
	  
	  scope f,err = io.open("foobar")
	  local x,y,z -- regular locals
	  
	  -- -----------------------------------------
	  -- all variables of type 'scope' are closed
	  -- -----------------------------------------
	end

  The current behavior with for (the four parameter that is "closed") can be
kept.

> > However the ugly syntax for a constant declaration is the side effect
> > of this; and that is a heavy price to pay. Given that the constant
> > feature seems to have been added because it was 'free' - perhaps, it
> > shouldn't be added to the language.
> 
> Agreed.

  Unless we can get global constants (or constants in a table) then yes, I
agree, the <const> attribute doesn't seem to be all that useful.

  Agreed.

  -spc