On Monday, 16 September 2019 at 10:06:55 UTC, Walter Bright wrote:
> 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.

Sincere question: do you want people to experiment with it? If so, in what way? People have already come up with holes in your proposal, and you've essentially said that you didn't mind them; so what would people confirming that these holes still exist in the preview implementation change?

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.

I don't understand the point of this review thread.

I know I've been hostile to this proposal, but beyond the object-level problems (which I won't repeat), there seems to be a problem of process here.

Reviewers have given feedback. Walter has, as you yourself noted, declared that feedback was invalid and already covered by the existing proposal; as such, the proposal is being posted again with no content change.

Like, I get that it isn't your job to agree or disagree with Walter on an object level; but on a process level, something clearly isn't working, and it feels like you should intervene. Either by putting your foot down and asking Walter make changes (like, any changes at all); by having some sort of mediator role between Walter and reviewers, maybe by organizing a chat or something; or by fast-tracking the proposal all the way and skipping the final review.

Because right now, I have to agree with Exil from last thread: I'm saying this with all the respect I have for you, but this is a charade. You're asking for feedback that we know for a fact Walter will ignore, because he has ignored all feedback given so far.

On Monday, 16 September 2019 at 16:51:41 UTC, Olivier FAURE wrote:

> I don't understand the point of this review thread.
>
> I know I've been hostile to this proposal, but beyond the object-level problems (which I won't repeat), there seems to be a problem of process here.
>
> Reviewers have given feedback. Walter has, as you yourself noted, declared that feedback was invalid and already covered by the existing proposal; as such, the proposal is being posted again with no content change.
>
> Like, I get that it isn't your job to agree or disagree with Walter on an object level; but on a process level, something clearly isn't working, and it feels like you should intervene. Either by putting your foot down and asking Walter make changes (like, any changes at all); by having some sort of mediator role between Walter and reviewers, maybe by organizing a chat or something; or by fast-tracking the proposal all the way and skipping the final review.
>
> Because right now, I have to agree with Exil from last thread: I'm saying this with all the respect I have for you, but this is a charade. You're asking for feedback that we know for a fact Walter will ignore, because he has ignored all feedback given so far.

It is not my place, with any DIP, to "put my foot down". The process does not require any revisions between review rounds. It is 100% up to the author to accept or reject feedback. Most of the DIPs that have gone through the process change very little between Community Review and Final Review.

The purpose of the Final Review is to provide one final chance for any major points of feedback that might have been missed in the previous review rounds. Again, it is up to the author, not me, to determine if the feedback is valid and whether or not to proceed.

I'm a shepherd, not a gatekeeper.

If you'd like to have a discussion about the DIP process, please start a new thread. This one is not the place for it.

Thanks!

On Monday, 16 September 2019 at 09:13:48 UTC, Mike Parker wrote:
 DIP 1021, "Argument Ownership and Function Calls", is now ready
> 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.
>
> 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

The problem with this DIP is it a part of some bigger picture (which includes DIP1000, DIP25 and probably other stuff) and it seems no one understands what this bigger picture is. TBH, it's not at all clear to me that even Walter knows what the end result will be. Maybe he's just making it up as he goes along?
Without understanding the whole thing there is not much to discuss. Maybe it's a good idea, maybe not. Who knows. Anyway, my opinion is all this stuff designed to support @nogc turn D into a mess. Why not just use Rust instead?

On Monday, 16 September 2019 at 16:34:38 UTC, Olivier FAURE wrote:
> 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.

You are not a moderator here, so stop acting like one.

- Alex

On Monday, 16 September 2019 at 10:06:55 UTC, Walter Bright wrote:
> 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.

Which IRC it been implemented couple of days ago. Not very much time to kick the tires so to speak.

- Alex

On 16.09.19 18:34, Olivier FAURE wrote:
> 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.

I don't think there's any need to be sorry. Your reaction is appropriate.

On Monday, 16 September 2019 at 14:45:49 UTC, 12345swordy wrote:
> 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

Rust's implementation is much more complex than what is going to be capable of being implemented in D. So unless you're proposing creating the exact same feature with the exact same rules then that reference means nothing.

What I find funny is that the DIP didn't change at all. I hear "write a DIP" all the time whenever something comes up. This DIP is so barebones, I expect Walter to hold himself to same standard as he holds others to. I don't know why this is even going through the DIP process. It's obviously going to be added even if the DIP was an empty page. This solves a problem that is already solved by using a GC.

The only example provided by the DIP still works (though you do have to make malloc/free @trusted). So the only real use case I can see of this is to prevent use-after-free bugs, but you can't even do that cause you can't use malloc/free in @safe. Even if you could, the current implementation doesn't stop it from being freed.

After using it for a little bit, the section on breaking changes should definitely be expanded. "Unknown how prevalent this pattern is". I feel this will break a lot of code. Using @system/@trusted isn't a real solution if someone is actually using @safe. Especially when you consider cases like foreach():


Currently seems to be a bug, doesn't take into consideration arrays inside foreach loops. But considering that you can't do it outside a loop, you probably shouldn't be able to do it inside the loop either.

    @safe:

    void foo(ref int, ref int) {

    }

    void test() {
        int[5] arr;

        // foo(arr[0], arr[0]); // error here

        foreach(size_t i, ref int a; arr) {
            foo(a, arr[i]); // but ok here
        }
    }

Another issue:

    @safe:


    void foo(ref int, ref int) {
    }

    void test() {
        int b;

        int* a = &b;
        int* c = &b;

        // foo( b, b); // error

        foo( *a, *c); // but this is ok
    }

On 9/16/2019 11:59 AM, 12345swordy wrote:
> Which IRC it been implemented couple of days ago. Not very much time to kick the tires so to speak.

The PR has been around for a month. It was pulled a couple days ago.