Language lawyer corner: object liveness

[Sergey Zakharchenko <doublef.mobile@...>]

Hello list,

5.4 somehow turned attention of many people to finalization, and how
they were relying on something that was there in the code but never
actually documented. Lua (just like many other languages) can (but
doesn't have to) clean up stuff as soon as it detects it cannot
possibly be used by regular code (I assume this means using
debug.getlocal & friends is not permitted). E.g. consider the
following:

local function f()
   local t={g()}
   ... -- code that never uses t
   return t.x
end

A sufficiently advanced optimizer knows that t's constructor cannot
create any non-numeric fields. It also knows t doesn't escape (as it
isn't used anywhere), so t.x == nil. Therefore, it doesn't need t at
all, and rewrites f to:

local function f()
   g() -- called for side effects only
   ... -- code that never uses t
   return nil
end

One way to avoid this if needed seems to be to put code that does
something side-effectful (and possibly error-throwing) but only on a
condition that you know never happens, but the optimizer can't prove
it. E.g. "_G[nil] and print(t)".

The problem is that people often need to have "trust me, I need the
variable to stay put but I also don't want to have to remember to do
something meaningful at the end of the block to it" semantics and it
seems a bit tricky to achieve. Maybe this new annotation syntax could
help?..

Best regards,

-- 
DoubleF