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

[Exil]

On Wednesday, 17 July 2019 at 23:26:20 UTC, Walter Bright wrote:
> On 7/17/2019 11:59 AM, Olivier FAURE wrote:
>> The current example isn't good enough. It's not @safe (it 
>> calls free() directly), it's not RAII (the structure doesn't 
>> manage its own memory),
>
> That's not the point. A container with an @safe interface can 
> do this, for example, simply by appending to the container 
> contents the pointer to the old contents can be invalidated. 
> The point of the example is to illustrate the problem clearly, 
> not obfuscate it with the complexities of a container object.

You are not limited to one example. Showing an implementation 
using a common RAII pattern to illustrate why it isn't sufficient 
and why it requires a new feature to replace/complement it. RAII 
is part of the reason why you should never be calling free 
directly to begin with. And the borrowing feature from rust very 
closely resembles std::unique_ptr from C++.

> More generally, any time there are two mutable pointers to the 
> same memory object, one can invalidate the other. This is the 
> principle pointed out in the "Prior Work" section. The DIP is 
> not intended to be a tutorial on this, which is why there's a 
> link to more explanation. It has nothing to do with RAII, and 
> thinking about it in terms of RAII will miss the generality of 
> the concept.

Showing an example that doesn't use malloc/free or something 
similar to it, would be more beneficial then. As malloc/free 
generally is replaced by RAII and isn't/shouldn't be used 
directly anyways.

How does the feature differentiate between GC and non-gc 
allocated pointers? If I label one function @live won't this 
limit all pointer operations, even though it is only really 
relevant to non-gc pointers? This seems like two different 
features clashing against one another, both trying to do the same 
thing but interfering with one another.