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

deadalnix deadalnix at gmail.com
Sun May 29 00:26:10 UTC 2022


On Sunday, 29 May 2022 at 00:22:03 UTC, Rikki Cattermole wrote:
> Walter suggested that I create a thread for an idea I've had 
> for memory ownership & lifetimes.
>
> The basic explanation is that every variable (including 
> temporaries and returns) are always in reference to other 
> variables. So that the order of destruction is correct and 
> nothing escapes its owner (they can be bundled unless scope is 
> involved).
>
> These examples come from a talk with Timon a couple of days ago 
> on Discord. His existing dislike for this idea is that it 
> conflates different levels of indirection.
>
> My worked example:
>
> ```d
> int[] array = [1, 2, 3]; // ownership: []
> // arg ownership: [] (not ref/out)
> // return ownership: [first argument] -> [array]
> int* got = func(array); // ownership: [array]
>
> int* func(int[] source) {
>   int[] slice = source[1 .. 2]; // ownership: [source]
>   int* ptr = &slice[0]; // ownership: [slice, source] -> 
> [source]
>   return ptr; // ownership: [ptr] -> [source]
> }
> ```
>
> A question Timon came up with that I answered:
>
> ```d
> int[][] func(int[] a, int[] b){
>     return [a,b];
> }
> ```
>
> (for return value): ``// ownership: [first argument, second 
> argument]``
>
> This ticks a lot of the boxes I'm using as preferable 
> acceptance criteria:
>
> 1. Inferred for anything non-virtual
> 2. Nothing outlives its owner
> 3. Fairly straight forward to understand

Yes, this is a good start. You have one major missing point: you 
need something to transfers ownership or you end up very limited.

https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/msr-tr-2012-79.pdf

All we need is one god damn type qualifier and we make DIP1000, 
@live, RC object, nogc exception and couple of other long 
standing problem a thing of the past.


More information about the Digitalmars-d mailing list