DIP 1021--Argument Ownership and Function Calls--Community Review Round 1

[aliak]

On Thursday, 18 July 2019 at 09:09:37 UTC, ag0aep6g wrote:
> On 15.07.19 17:23, Mike Parker wrote:
>> This is the feedback thread for the first round of Community 
>> Review for DIP 1021, "Argument Ownership and Function Calls":
>> 
>> https://github.com/dlang/DIPs/blob/793f83911fdc8c88c6ef34e6a36b5e11e3e574e5/DIPs/DIP1021.md
>
> The DIP isn't clear in what it is supposed to achieve. Is there 
> actual @safe code that can cause memory corruption currently, 
> which the DIP would prevent? Or would the DIP allow code to be 
> @trusted that can't be currently?
>
> As far as I understand, the DIP would allow `free` to be 
> @trusted in certain situations.
>
> I.e., this isn't okay currently:
>
>     struct S
>     {
>         byte* ptr;
>         byte* get() { return ptr; }
>         this(byte value) @trusted
>         {
>             ptr = cast(byte*) malloc(1);
>             *ptr = value;
>         }
>         void clear() @trusted
>         {
>             free(ptr);
>             ptr = null;
>         }
>     }
>
> ... because a function could call `clear` while already having 
> obtained `ptr`.
>
> But it would be with the DIP, maybe? Is that the point of the 
> DIP?
>
> Except it still wouldn't be 100% ok, because @safe code could 
> set `ptr = new byte;` and then `free` would be called on GC 
> memory.

There seems to be a lot of unclearness about this dip which a few 
failing and success cases would fix. I'm not sure why not just 
add a few examples to make it more clear...

Anyway, I think the dip has nothing to with any case other than 
the same variable appearing in the same statement. That is the 
extent of this DIPs scope, but it's quite unclear from the DIP. I 
think it basically asks:

"is the same variable seen in a single statement as an argument 
to more than one ref parameter?" if they are constant then ok, if 
not then error.

so:

f(v, v.ptr) ; // the check applies

a = v.ptr
f(v, a); // the check doesn't apply