DIP 1021--Argument Ownership and Function Calls--Final Review

[Exil]

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