What should happen here?

[IGotD-]

On Wednesday, 22 September 2021 at 19:30:37 UTC, Paul Backus 
wrote:
>
> Either (a) the compiler must assume, pessimistically, that a 
> pointer passed to a function may be stored somewhere the GC 
> can't see it, and therefore must be preserved in local storage 
> until the end of its lexical lifetime, or (b) the user must 
> manually signal to the compiler or the GC that the pointer 
> should be kept alive before passing it to the function.
>
> Given how error-prone option (b) is, I think (a) is the more 
> sensible choice. Users who don't want the pointer kept alive 
> can always opt-in to that behavior by enclosing it in a block 
> scope to limit its lifetime, or setting it to `null` when 
> they're done with it.

The problem with a, is that eats up resources such as 
registers/stack, preventing better code generation. The compiler 
might choose to put it on a register and that way block that 
registers that could be used for better optimization. Also 
registers load/store on stack will increase.

Free after last recently used is a perfectly sane assumption. 
Also if you are using RC, the compiler should decrease the 
reference count after last use in order to free up resources like 
registers. Therefore I think to define that the resource must be 
kept alive inside the entire scope hurts code generation while 
the benefit is low.

Also option a, is in 99% of cases good because as long the 
resource is being used it must be *somewhere* (assuming you are 
using D all the way) which means the D GC will find it.

The problems described in this thread are really fringe problems 
and I think it could be resolved by other means. KeepAlive is one 
of them and it is also a GC agnostic, works on any GC. I rather 
say b is the better alternative, covering for those very special 
cases.