Re: Query about to-be-closed semantics

[Francisco Olarte <folarte@...>]

Arnaud:

On Fri, 14 Jan 2022 at 12:51, Arnaud Delobelle <arnodel@gmail.com> wrote:
> Yes, but I don't really see how it relates to my question.  My
> question is in essence why check for a property that we require to be
> true later, given that it could change in the meantime?

Got it wrong. The check is certainly useful for me ( I routinely
assign results of functions building closable objects, this catches
errors early ) but given your example proves they even tolerate absent
metatable on returns it could probably be skipped ( for some minot
speed gain? ). Language definers would need to answer that.
...
> There doesn't need to be more complexity, for example the check for a
> __close metamethod when the to-be-closed variable is defined could be
> removed altogether.  The programmer will find out anyway when the
> variable goes out of scope.

Of course, I was working on wrong premises, I assumed you were asking
for the change to be fobidden. It seems I interpreted " 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." wrongly and what fixed on that directions.

> Also I am not saying the semantics should be changed, I am interested
> in the considerations that made them what they are.

Got it. I would probably have done it twice similar to what it is ( I
regularly do that kind of stuff, early checking, for debug aid ), but
I do not know why they did it.

  FOS.