Escape Analysis & Owner Escape Analysis

[Richard (Rikki) Andrew Cattermole]

On 30/08/2024 10:06 AM, IchorDev wrote:
> On Saturday, 24 August 2024 at 13:20:36 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> 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;
>> ```
> 
> That’s what I meant—there are situations where you can’t reassign the 
> pointer even though it’s not referenced.
> 
> Also, a couple of minor suggestions:
> First one, which is a bit silly: I assumed the way to indicate return 
> via `ref`/`out` parameters would be `@escapevia(ref)` or 
> `@escapevia(out)`. Using the parameter name makes more sense, but having 
> a way to apply the escape to all `ref`/`out` parameters would be neat. 
> Again, not exactly a showstopper.

How often do you have multiple ref/out parameters and will be escaping 
to all of them for the same input parameter?

Currently I don't believe a special case is necessary for this, so needs 
to be more than just a nice to have.

> Second thing: `@escapevia` is very long (especially when combined with 
> its identifiers), and doesn’t even sound grammatically correct—it should 
> be `@escapesvia`, as in ‘int x escapes via return’. If we don’t care 
> about it reading correctly then `@escapeset` makes more sense—that’s 
> what the DIP refers to it as—and the natural shortening would be 
> `@escape`. Of course, I’d prefer something **really** short like `@esc` 
> because typing is painful (I’m not really typing this message) but also 
> because with identifiers like `__parameters` my fully-attributed library 
> function signatures will look like utter earwax. I know you’ll say ‘but 
> they can be inferred’, but unfortunately documentation generators don’t 
> read between the lines like that; and I want my users to be able to know 
> what parameters my functions escape without reading my function bodies 
> or having to `pragma(msg, typeof(someFunction))`.

I could do ``@escape(...)``.

But yeah, if you're annotating good chance you'll want to do one 
parameter per line. Not ideal, but if you want control, some sacrifices 
towards convenience is gonna happen.