Re: Language lawyer corner: object liveness

[Thijs Schreijer <thijs@...>]

> On 6 Jun 2019, at 08:21, Sergey Zakharchenko <doublef.mobile@gmail.com> wrote:
> 
> 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
> 

I get the explanation. But what is the problem? In the example you gave everything works as expected, optimised or not.

Thijs