DIP 1021, "Argument Ownership and Function Calls", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter (the author in this case) and Átila for the Formal Assessment.

Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

The current revision of the DIP for this review is located here:

https://github.com/dlang/DIPs/blob/1d78cdf1613911439848a49e9053a7bbf5a9de46/DIPs/DIP1021.md

In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on September 30 unless I call it off before then.

Thanks in advance for your participation.

DIP 1021 can be experimented with as the code is now in the compiler and enabled with -preview=useDIP1021. I'd expect some trouble with it as it doesn't have much wear on the tires.

On Monday, 16 September 2019 at 09:13:48 UTC, Mike Parker wrote:
> https://github.com/dlang/DIPs/blob/1d78cdf1613911439848a49e9053a7bbf5a9de46/DIPs/DIP1021.md

As Andrei said at DConf 2019, a DIP must be thorough enough such that it should be able to be correctly implemented by a vengeful ex. Currently, the description does not pass this test:

> Therefore, if more than one reference to the same data is passed to a function, they must all be const

```
void foo(scope int[] x, scope int[] y);

void main() {
    int[2] a = [100, 200];
    int[2] b = [100, 200];
    foo(a[], b[]); // not allowed in vengeful implementation!
    // The same data is passed, so parameters x and y must be const
}
```

```
void foo(scope immutable int[] x, scope immutable int[] y);

void main() {
    immutable int[4] a;
    foo(a[], a[]); // not allowed in vengeful implementation!
    // parameters are immutable, not const
}
```

You might say "it is obvious what I meant" but that reasoning didn't prevent DIP1016 [1] (Manu's ref T accepts r-values) from being rejected.

> This builds on the foundation established and tested by DIP 25 and DIP 1000

This doesn't help defining "the same data" either, DIP 1000 is superseded and there is little to no specification on how `scope` currently works with the -dip1000 flag.

[1] https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md

On Monday, 16 September 2019 at 09:13:48 UTC, Mike Parker wrote:
> DIP 1021, "Argument Ownership and Function Calls", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter (the author in this case) and Átila for the Formal Assessment.
>

does help this DIP with next situation or another option already exists in D?
https://run.dlang.io/is/LQJ79M

dmd -dip1000 ....
---------------------------
import std;

struct Data {
    private void[10] buf;
    private void* ptr; // some data

    //TODO. OT
    // should it be possible to initialize pointers to internals in the default constructor for structs? does DIP-xxxx(idr) solve it? whether its necessary?
    // this() { ptr = buf.ptr; }

    // I want that data can be used only at block { that requested it }
   	void[] data() @trusted return scope {
       	return ptr[0..10]; // returns some internals
    }
}

// user func that work with Data internals that shouldn't run away
// user can forget to use "scope"
void[] userFunc( ref Data d ) @safe {
    auto tmp = d.data;
    // FIXME
    // tmp shouldn't run away.
    // "scope" in user hands is not solution. (scope ref Data d)
    // lib should control access to lib internals not the user.
    return tmp;
}

void main() {
    Data d;
    userFunc( d );
    "data runs away. and dip1000 is enabled.".writeln;
}

On Monday, 16 September 2019 at 10:46:41 UTC, a11e99z wrote:
> On Monday, 16 September 2019 at 09:13:48 UTC, Mike Parker wrote:
>> DIP 1021, "Argument Ownership and Function Calls", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter (the author in this case) and Átila for the Formal Assessment.
>>
>
> does help this DIP with next situation or another option already exists in D?
> https://run.dlang.io/is/LQJ79M
>
> dmd -dip1000 ....
> ---------------------------
> import std;

one more indirection:
https://run.dlang.io/is/h1ahew

On 16.09.19 11:13, Mike Parker wrote:
> The current revision of the DIP for this review is located here:
> 
> https://github.com/dlang/DIPs/blob/1d78cdf1613911439848a49e9053a7bbf5a9de46/DIPs/DIP1021.md 

Walter hasn't changed a single thing, so the criticism from the last round still applies.

I'll repeat mine (and maybe elaborate on it): The DIP does not show what benefit it brings. In the Rationale section, it presents buggy code. In the Description section, it proposes a language change. But it fails to show how the change would help prevent the bug.

In particular, "the checks would only be enforced for @safe code", but the bad code in the given example calls `free` which means it can be @trusted at best. So it seems like the DIP wouldn't apply to its own motivating example.

On Monday, 16 September 2019 at 11:05:21 UTC, ag0aep6g wrote:
> On 16.09.19 11:13, Mike Parker wrote:
>> The current revision of the DIP for this review is located here:
>> 
>> https://github.com/dlang/DIPs/blob/1d78cdf1613911439848a49e9053a7bbf5a9de46/DIPs/DIP1021.md
>
> Walter hasn't changed a single thing, so the criticism from the last round still applies.
>
> I'll repeat mine (and maybe elaborate on it): The DIP does not show what benefit it brings. In the Rationale section, it presents buggy code. In the Description section, it proposes a language change. But it fails to show how the change would help prevent the bug.

It been shown here in the exiting work section.
https://doc.rust-lang.org/1.8.0/book/references-and-borrowing.html#the-rules

-Alex

On Monday, 16 September 2019 at 14:45:49 UTC, 12345swordy wrote:
> It been shown here in the exiting work section.
> https://doc.rust-lang.org/1.8.0/book/references-and-borrowing.html#the-rules

A link to the documentation of another language is not good enough for a DIP.

On Monday, 16 September 2019 at 15:11:07 UTC, ag0aep6g wrote:
> On Monday, 16 September 2019 at 14:45:49 UTC, 12345swordy wrote:
>> It been shown here in the exiting work section.
>> https://doc.rust-lang.org/1.8.0/book/references-and-borrowing.html#the-rules
>
> A link to the documentation of another language is not good enough for a DIP.

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

On Monday, 16 September 2019 at 15:33:31 UTC, 12345swordy wrote:
> https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

I'm going to be blunt, moreso than usual: this is a tense discussion about a contentious subject, and right now you're adding nothing of value to it.

Yes, DRY is a good principle in software development, in general. It doesn't really apply to a debate process, which doesn't have the same constraints as a body of code or documentation.

More importantly, I've already gone on at length about why Rust isn't directly comparable to D, and why this proposal in particular is very different from Rust's memory model, and as such needs a deeper analysis than "we'll do it like Rust".

So I think as a matter of courtesy, you should probably read the arguments that have already been made on the subject before lecturing other people about not repeating things.

Sorry, I realize I'm being hostile. But we've been debating this for weeks, and we really don't need another surface level back-and-forth like you're doing.