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

Olivier FAURE couteaubleu at gmail.com
Thu Sep 19 08:31:44 UTC 2019

On Thursday, 19 September 2019 at 02:59:22 UTC, Walter Bright 
> On 9/16/2019 9:34 AM, Olivier FAURE wrote:
>> 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".
> The point that matters here is the idea of having only one 
> mutable pointer to a memory object at a time, or having many 
> const pointers to a memory object. But not both.
> The details of how one achieves that can vary from language to 
> language, but I believe as long as that principle is followed, 
> it will be sound.

Leaving aside my other gripes with this DIP, I think that broader 
vision is debatable.

It's how Rust does it, but I would argue [1] that the Rust model 
is way too restrictive. Its cuts off a lot of designs that are 
provably safe, and it basically forces you to rework your design 
from the ground up, which is kind of a problem for a language 
with existing codebases.

Your solution to that problem is to have a @live function, with 
the idea that users can upgrade their code incrementally and 
avoid a complete refactor. I'm extremely skeptical that idea can 
work, because @live functions will make assumptions about the 
pointer graph passed to them (no duplicate mutable pointers) that 
non- at live functions calling them won't be obligated to uphold. So 
calling a @live function from a non- at live function won't be safe.


More information about the Digitalmars-d mailing list