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