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

[Olivier FAURE]

On Friday, 19 July 2019 at 20:03:22 UTC, Walter Bright wrote:
> 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.

Counter-example:

     struct S1 {
         byte* ptr;

     @safe:
         ~this() { reset(); }
         ref byte get() return { return *ptr; }

     @trusted:
         void init() { ptr = cast(byte*)malloc(1); *ptr = 0; }
         void reset() { free(ptr); ptr = null; }
     }

     byte* identity(ref return byte b) @safe {
         return &b;
     }

     void useS() @safe {
         S1 s = S1();
         s.init();

         byte* ptr = identity(s.get());
         s.reset();
         *ptr = 1; // BOOM
     }

>> 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 presented that specific problem 22 days ago: 
https://github.com/dlang/DIPs/pull/158#issuecomment-506633378

You said it didn't apply to your case, which is why I asked you 
to demonstrate your case. You said your example already did.

I (and several other people) pointed out a non-subjective problem 
with your example: it doesn't compile any differently before and 
after the DIP as presented. Which I have repeated several times, 
and you still haven't acknowledged.

I'm going to repeat that one more time: your example does not 
compile *any differently* before or after the proposal as you 
describe it, ***and I'd appreciate if could acknowledge it in any 
way at all***.

So its power to facilitate communication is kind of null.

Yes, I can make guesses at what you intend. This was, you'll 
recall, the same argument Manu made for DIP 1016, that the 
underlying concepts were clear enough, and that there was no need 
for giving specific semantics because anyone should understand 
the general concept (you can make references to rvalues).

That's not how a review process works. A reviewer shouldn't have 
to prove their worth before the submitter includes a single valid 
example in their proposal (which, I'll note, you still haven't 
done). Reviewers shouldn't have to write up the examples 
themselves like we did and conjecture about whether they match 
the author's intent.

Like, I'm not sure that you realize, but the process of 
communicating with you is kind of painful and makes me want not 
to bother at all. You seem to take anybody asking you for 
additional details as something between a personal insult and an 
annoying waste of time. In fact, you've spent more time arguing 
about not writing examples than it took me to write a single 
example.

In fact, in the three weeks you've been arguing that writing 
examples was a waste of your time, I've written four different 
examples trying to understand your proposal.

I'm honestly kind of done here. I'm getting sick of putting 
effort into understanding your proposal and trying to communicate 
with you that you're neither matching nor even acknowledging. 
I'll just work on my own draft and leave this DIP alone.