> If someone sets a to-be-closed variable with a value with a given __close, and than they change that __close before the value is closed, and they cannot figure out which one will be called, it seems healthy to keep them ignorant about that.
In the case of __gc, you seem to think otherwise.
Regardless, the current behavior with respect to the presence and time of evaluation of __close seems unnecessarily complicated. Can you explain what is gained by having to check the validity of __close twice? In the first check, luaF_newtbcupval() obtains the metamethod just for the sake of checking that it exists, it is not used nor stored for later use. In the second check, callclosemth() does not seem to have a real need to raise an error if there is no __close, which it actually does not do if another, seemingly arbitrary, condition is satisfied.
So, as far as I can tell, lines 155, 156, 199, 200 and 201 of lfunc.c (of 5.4.0-beta-rc1) can be deleted without breaking anything. The resultant behavior is then simple: any local can be marked for closing; such locals are constant; when leaving the scope of a local thus marked, the __close metamethods of its value, if present, will be called. Note that this behavior is more alike that with __gc, when it is not an error that an object previously marked for finalization does not have a __gc when finalization begins.
Cheers,
V.
