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

[rikki cattermole]

On 30/05/2022 8:26 AM, Walter Bright wrote:
> where the declaration of foo() is separated (maybe in another file) from 
> its definition.
> 
> Your proposal requires all the source to be available, and no "header" 
> declarations. It also won't work for pointers to functions and delegates.
> 
> To make those work will require annotations - the same reason D has 
> `scope` and `return` annotations.

Indeed.

I don't think you can get around having annotations for lifetime stuff 
for function pointers or virtual methods. You simply are going to need them.

Here is a common bit of code I've got:

```d

struct Thing {
@safe nothrow @nogc:

     StringBuilder_ASCII toString(RCAllocator allocator = 
globalAllocator()) @trusted scope {
         StringBuilder_ASCII ret = StringBuilder_ASCII(allocator);

         ...

         return ret;
     }
}
```

The fact that it is called toString is immaterial (just want to point 
that out).

There are two sets of function annotations, at the struct scope level 
and at the method level. Scope on the method should actually be at the 
struct level, its not due to[0]. So we can ignore that one as it is 
unrelated to the problem at hand.

But the @trusted on the other hand, that is DIP1000 related. Since 
without it, DIP1000 is seeing ret and even though the this pointer and 
anything in it, is not stored in anyway inside of ret, ret is inferred 
as scope and cannot be returned.

While I'm sure we can special case this to get it to work, this is a 
pretty good example of where things that should be working right now, 
are not.

I know in my original post I didn't talk about how to turn this sort of 
thing on, in the past I used scope as a type qualifier to do it in my 
thought experiments. Which would work in all D code regardless of 
function annotations.

[0] https://issues.dlang.org/show_bug.cgi?id=23142