Idea: Ownership & lifetime escape analysis by variables in reference to

[Ola Fosheim Grøstad]

On Sunday, 29 May 2022 at 12:11:01 UTC, rikki cattermole wrote:
> I did mention elsewhere that I previously used scope as a type 
> qualifier to do this.

I guess what I am saying is something like this:

I think you would get better yield for your time investment by 
pursuing how to add barriers and figuring out how one could write 
@trusted code in such a landscape than anything related to 
advanced escape analysis in the context of verification of *D 
code* (optimization is ok, because then you will choose a best 
effort strategy, verification is all-or-nothing).

To understand what is needed for solid escape analysis, let us 
take the two-element queue example. You could unroll the loop. 
Replace ```a[0]``` with ```a0```, ```a[1]``` with ```a1``` and 
all ```a[i]``` accesses with a conditional (or switch). Then 
analyse this with an algorithm/solver that can deal with 
branches. Or something along these lines. A lot of machinery even 
for the simplest datastructure! And then we have the slice 
scenarios with aliasing, where modifying the content of one slice 
could modify basically any other parameter.

It would be so much easier to just add @stack as an optimization 
hint where you want something to be put on the stack, and let the 
compiler generate a report of where it failed, why and how to 
improve the code.

(For DIP1000 to make sense it must be a able to deal with more 
complexity than most of your code, otherwise it will break down 
whenever you need to modify existing code.)