Escape Analysis & Owner Escape Analysis

[IchorDev]

On Saturday, 24 August 2024 at 12:20:13 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> To those who have tried DIP1000 and then dumped it, I am 
> interested to know how you find the owner escape analysis of 
> this proposal in terms of being restrictiveness.
> Please evaluate it, so I can know if there is a pattern that 
> needs resolving (if possible).

Unfortunately I never used DIP1000 much. I do like the look of 
your pattern though.

> ```d
> int* borrow() @escapevia(return);
> ```

So this `escapevia(return)` is the same as `return`?

> ```d
>     int* borrowed1 = input.borrow();
>    // input is an owner, and therefore protected due to the 
> borrow borrowed1
>    input = RC.init; // Error
>    int* borrowed2 = second(borrowed1);
>    // borrowed1 is an owner, and therefore protected due to the 
> borrow borrowed2
>    borrowed1 = null; // Error
> ```

I can imagine this could cause very long annoying chains of ‘ugh 
just let me reuse this pointer’. Disallowing modifying the 
pointer itself is really odd, but I see *why* it’s done—otherwise 
you might have to reckon with there now being several ‘owners’ 
created downstream. I just wish there was a nice way around that.

If this pattern will genuinely solve the various issues people 
have with DIP100, then I hope it gets implemented.