Re: Query about to-be-closed semantics

[Francisco Olarte <folarte@...>]

Arnaud:

On Fri, 14 Jan 2022 at 10:49, Arnaud Delobelle <arnodel@gmail.com> wrote:
... example clearing metatable on a to be closed leading to an error snipped.

> That makes sense as I removed the metatable from t before "closing
> time".  However, when defining c
>
>     local c <close> = t
>
> at that point the Lua runtime checks that t indeed has a close
> metamethod and produces an error if that's not the case.  Now it feels
> to me that this check is conflicting with the behaviour above as this
> check is not so meaningful if what it checks can be subsequently
> invalidated.
>
> Has this been given consideration?   For example the runtime could
> remember the close metamethod at variable definition so it will
> definitely be the one used when the to-be-closed variable comes out of
> scope.

Any competent programmer can normally crash is language of choice (
note I loosely consider crash the error, although it is the expected
behaviour ). You could as easily have defined __close as  function()
if (math.random()>0.01 then error("My, aren't you unlucky!") end end
which will avoid that check. Or as "self:real_close()". Or have set
__close to error in the metatable.

I'm sure your exemplified hole can be closed, but I'm not sure the
added complexity is worth it, giving one should be prepared to an
error in the closing proccess, "If there is any error while running a
closing method, that error is handled like an error in the regular
code where the variable was defined. After an error, the other pending
closing methods will still be called.", and this is beautifully
handled, the only thing I would think on adding to it, and only if it
was a simple, one line patch, would be distinguishing the case nil-not
on metatable vs nil-object has no metatable as a purely debugging aid.

Francisco Olarte.