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

[Walter Bright]

On 9/19/2019 1:31 AM, Olivier FAURE wrote:
> 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.

That's true. Functional programming has the same problem. But we find it 
advantageous to support FP when people want to use FP.

D's transitive const has also proved difficult to retrofit into existing code 
(like the DMD source code).


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

That's right, it won't be. Just like if you call an @trusted function from an 
@safe one, it won't be safe, either (at least the compiler can't check it for you).


 > [1] https://gist.github.com/PoignardAzur/9896ddb17b9f6d6f3d0fa5e6fe1a7088

I haven't studied that. Is it a 100% solution? I know there's one being worked 
on for C++, but it's an 80-90% solution.

D needs to have a 100%, mechanically checkable, solution.

We have 100% for transitive const and function purity. It's hard to get code to 
pass, but worth it when one succeeds. The Ownership/Borrowing solution is 100% 
which is what is appealing about it.