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

[Olivier FAURE]

On Monday, 15 July 2019 at 15:23:32 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community 
> Review for DIP 1021, "Argument Ownership and Function Calls":
>
> https://github.com/dlang/DIPs/blob/793f83911fdc8c88c6ef34e6a36b5e11e3e574e5/DIPs/DIP1021.md
>
> All review-related feedback on and discussion of the DIP should 
> occur in this thread. The review period will end at 11:59 PM ET 
> on July 30, or when I make a post declaring it complete.

I want to strongly state that this DIP is too vague and 
unpolished to justify its integration to the language standard, 
provided it's being judged by the same standards as previous DIPs.

In fact, this DIP reminds me a lot of DIP 1016 (the "rvalue ref" 
one), in that it suffers from similar problems.

To quote my post-rejection analysis[1] of DIP 1016:

> Now, you might say (and have said in the past) "Well that's 
> obvious, you just need to do X, unless Y, in which case Z", but 
> the point is that all these considerations *need to be in the 
> proposal*.
>
> As it is, the proposal doesn't have any negative space. That 
> is, it explains what the feature should look like, but it 
> doesn't define boundaries, where the feature is or isn't 
> allowed to be used.
>
> Defining negative space is important because it's how you find 
> corner cases, cases where the correct behavior seems obvious, 
> and yet when you spell it out it turns out everyone disagrees 
> on how it should be handled.
>
> Right now, the DIP doesn't address potential corner cases [at 
> all].

In particular, one area in which this proposal is lacking is 
examples.

Now, Walter has expressed that a spec document isn't made any 
clearer by a large number of examples, or by having more complex 
examples, and I mostly agree.

But the problem with the current examples is that they don't 
cover any changes in behavior introduced by the proposal, let 
alone corner cases. There should be at least one example showing 
@safe code that compiles before DIP 1021, and gives an error 
message after the proposal. The example would show a simplistic 
RAII-style container, with @safe or @trusted getters and setters; 
something like:

     struct S1 {
         byte* ptr;

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

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

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), and it doesn't even show what a syntax error would 
look like.

Ideally, there should also be additional examples illustrating 
nuances of the proposal; eg, since the proposal is meant to apply 
to ref and not pointers, there should be examples showing code 
that compiles with pointers and doesn't compile with refs.

Examples aside, this proposal is also way too vague and informal. 
The proposal says inter-statement checking isn't done, but it 
doesn't explain what is or isn't inter-statement checking. Do 
nested expressions count? Are you allowed to do this:

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

To quote Andrei's post-rejection analysis[2] of DIP 1016:

> It has multiple problems of informality and vague language that 
> have worked together to cause said misunderstanding. [...]
>
> The DIP must convince the reader, and in a way the reader does 
> not "owe" the DIP. [...] Of course we don't want to be as harsh 
> as academics could get, but we don't want to transform DIP 
> acceptance into a farmers market bargaining process.
>
> [...] In a thorough submission, however, there would have been 
> many places that clear that up:
>
> * Use of a distinct notation (non-code non-text font for 
> metalanguage, i.e. general expressions);
>
> * Description of the typechecking process, with examples of 
> code that passes and code that fails;
>
> * Several places in text in which it is explained that rvalues 
> resulted from implicit conversions are not eligible;

I think a lot of advice in Andrei's review is good advice for 
writing any DIP, and I think it absolutely applies to this one.

[1]: 
https://forum.dlang.org/post/hxqjetbtzlzzaxnpwgyk@forum.dlang.org
[2]: https://forum.dlang.org/post/q2u429$1cmg$1@digitalmars.com