Escape Analysis & Owner Escape Analysis

[Richard (Rikki) Andrew Cattermole]

On 25/08/2024 1:15 AM, IchorDev wrote:
> 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.

Thanks!

>> ```d
>> int* borrow() @escapevia(return);
>> ```
> 
> So this `escapevia(return)` is the same as `return`?

Yes, except no.

``return`` maps to either the return value or the this pointer.

>> ```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.

You can assign to a variable, its just can't have any owners.

I.e. this will work:

```d
int* borrowed = acquire(owner);

borrowed = new int;
```