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

[Olivier FAURE]

On Friday, 19 July 2019 at 07:59:14 UTC, Walter Bright wrote:
> https://github.com/dlang/dmd/blob/master/src/dmd/root/outbuffer.d
>
> Look at line 408, peekSlice(). It returns a slice of data[].
>
> Now look at line 132, writeByte(). It calls reserve(1). Line 50 
> reallocates data[], invalidating the pointer returned by 
> peekSlice().
>
> Write a function that passes both the OutBuffer reference, and 
> the result of peekSlice(). In that function, call writeByte(). 
> Boom.

Alright, I'm going to cut to what I think is the heart of the 
problem.

     void someFunction()
     {
         auto buffer = OutBuffer(someData);
         auto slice = buffer.peekSlice();

         buffer.writeByte();
         slice[0] = 42;          // Boom
     }

As you're aware, nothing about your DIP stops the above case from 
happening. 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; presumably, your function 
that takes the OutBuffer reference and the result of peekSlice() 
wouldn't be @safe either, so it wouldn't even be stopped by your 
DIP.

> The example in the DIP is the same thing, minus the 470 lines 
> of other stuff.

Nobody is asking you to write a 470-lines example. People are 
asking you to write at least one example that would behave 
differently with your DIP than it behaves now.

Like, you insist on that, like the fact that we're asking for 
examples means we don't understand your DIP and thus we're not 
fit to judge it, or like we're being unreasonable and we're only 
asking because we're being capricious or something.

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.

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