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

[Walter Bright]

On 7/19/2019 1:49 AM, Olivier FAURE wrote:
> So I don't understand what the point of this DIP even is, given that for every 
> memory leak that you your DIP prevents, I could give you another way to express 
> it so that your DIP lets it pass.
> It doesn't close a loophole in @safe, because the core problem is that 
> writeByte() isn't actually @safe;

Any container that does its own memory allocation relies on @trusted code.

However, if that container exposes its internals by ref, then it is safe with 
this DIP, because ref does not span statements.


> Speaking personally, I'm not asking for examples because I don't understand your 
> proposal. The reason I'm asking for examples is that examples are a good medium 
> to support communication, and to suss out the deeper reasons people might 
> disagree about an idea.

It would have facilitated communication if you'd acknowledged you understood the 
example, but had a question about another specific case (and presented that 
example).


> I'm pretty sure I do understand your proposal, and I think it's fundamentally 
> flawed. I think you're trying to gradually implement the Rust memory model, and 
> you think that non-aliased function arguments are a good first step, that will 
> help determine how a full implementation should be rolled out. I think that 
> approach is unworkable, because the Rust memory model is kind of an 
> all-or-nothing feature, and gradually implementing it like you intend isn't 
> really feasible; I think DIP 1021, if it passes, will barely be noticed by 
> anyone, except as an annoyance, and won't bring any useful feedback for 
> designing a more coherent memory model.

D has been gradually implementing that memory model for some time now - DIP25 
and DIP1000 are examples. This is the next logical step.


> Because, again, DIP 1021 doesn't 
> actually bring any additional memory safety, because "use after free" in real 
> code almost never occurs in a way that could be stopped by DIP 1021.

It's a workable solution for containers that expose pointers to their internals 
via "ref", because "ref" is a restricted pointer. I've advocated for years that 
people use "ref" when exposing internals.