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

[Olivier FAURE]

On Wednesday, 17 July 2019 at 23:26:20 UTC, Walter Bright wrote:
> 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.

By "more explanation", do you mean the Rust tutorial? Because (1) 
pointing at an entire flippin' language and saying "There, that's 
prior work, just read it if you have any questions" seems pretty 
lazy to me, (2), this DIP obviously isn't trying to implement 
everything single Rust construct supporting borrowing (eg 
lifetimes, single initialization, and yes, interstatement 
checking), and D isn't a language made from the ground up like 
Rust, which means its implementation is going to be different in 
ways that need to be documented.

Like, is D going to implement the "one assignment, one move" rule 
from Rust? Lifetime parameters to structs?

> It has nothing to do with RAII, and thinking about it in terms 
> of RAII will miss the generality of the concept.

Rust does have RAII, though. In fact, containers like Vec<T> 
Box<T>, and Rc<T> rely explicitly on RAII, and can't work with 
lifetimes alone.

> A language specification does not specify the text of error 
> messages, merely that a particular configuration is not legal.

Yeah, but your examples don't even show any illegal configuration.

The DIP says "The checks would only be enforced for @safe code.", 
but your examples only show @system code.

> The current language spec makes it clear what a statement is 
> and what an expression is.

So:

     foo(identity(&s), s.get()); // Does this compile in @safe ?

> 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.

Can you show an example of this? If you don't want to add to the 
DIP, then in this thread?

Or even tell me whether the example code I already posted matches 
what you had in mind?

Right now, containers can already allocate memory to append new 
contents, so the DIP wouldn't improve that aspect. What they 
can't do is call free() on the old contents, except free() can't 
be called in safe code, which imply containers would need a 
@trusted method to free memory, which comes with problems the 
proposal doesn't address.