Gé:
On Mon, Jun 3, 2019 at 4:54 AM Gé Weijers <ge@weijers.org> wrote:
> The idea that every object reference must be assigned a slot that lasts until the end of a block/call is not required anywhere outside of the C interface of the PUC Lua implementation, you're making unwarranted assumptions about how things should work.
I'm asuming when the PUC guys say "accesible=live" they mean it, I'm
not even assuming slots or anything similar exists.
This is, I think, the crux of the disagreement here.
I will agree with you: as long as the documentation is written the way it is, such an optimization would be noncompliant with the standard.
However, I think the point you're missing is that this is a discussion of "but what if it wasn't documented that way?" Because the documentation can be changed, and that would open up avenues for optimization by relaxing certain guarantees. Yes, this would introduce a point of incompatibility with existing code, but Lua has never once claimed that compatibility across minor releases (as opposed to point releases) was guaranteed.
This would be inconvenient to you, no doubt, as you have code that depends on the current behavior. But part of the discussion of such a change would also need to include "what other changes would be necessary in order to support this use case?"
I assert that a "retain" decorator (whether using the <> syntax of const or toclose, or using some wrapper function along with <toclose>) would address your concerns, if this suggested change to the specification were to be pursued.
In light of this fundamental lack of alignment on the underlying intent of the discussion, the rest of this argument has been fairly meaningless.
/s/ Adam
