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

[Walter Bright]

On 9/19/2019 6:26 AM, Mike Franklin wrote:
> On Thursday, 19 September 2019 at 09:42:06 UTC, Walter Bright wrote:
> 
>> > [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.
> 
> There are two 100% solutions that I am aware of.  One is Rust's borrow checker, 
> which I'm assuming is already familar to all, and the other is Pony's reference 
> capabilities [1].  As the ownership and borrowing vision for D is being 
> polished, I think it would be worthwhile to become familiar with Pony's model 
> even if only to provide contrast and solidify existing ideas.
> 
> Graydon Hoare [2] and Niko Matsakis [3], both rock stars in the Rust community, 
> provided some interesting commentary on Pony's model.
> 
> [1] - 
> https://tutorial.ponylang.io/reference-capabilities/reference-capabilities.html
> [2] - 
> https://www.reddit.com/r/rust/comments/34rszb/pony_type_and_memory_safe_language/cqxkmm8/ 
> 
> [3] - 
> https://www.reddit.com/r/rust/comments/34rszb/pony_type_and_memory_safe_language/cqxvxky/

Thanks for the references.


> I'm really excited about where you're going with all of this, but this DIP does 
> seem like an odd thing to do in isolation from a complete ownership/borrowing 
> model.  It still seems to me that a complete 
> ownership/borrowing/reference-capabilities solution, in the general case, would 
> already handle the use cases addressed by this DIP.

An OB system would build on and extend this DIP, not replace it. It's the next 
step in:

1. DIP25 built on and extended the existing checks for returning the address of 
a local.

2. DIP1000 built on and extended DIP15 by adding checking for pointers, not just 
references.

3. DIP1021 built on and extended DIP1000 by adding the notion of OB for function 
parameters. Look at the implementation of DIP1021 - it is most definitely 
leveraging the code for 1 and 2.

A full OB system will leverage the code added for 3, too.

DIP1021 also has the advantage of trying out OB on a limited scale, and gently 
introducing D users to the concepts behind it.

Code modified to work with DIP25, DIP1000, and DIP1021 will not need a do-over 
for OB, it'll just be further down the same road. As you're well aware, 
upgrading Phobos to DIP1000 was a bit of a struggle, but I hope you'll agree it 
was well worth it. I suspect that going from pre-DIP25 to OB in one step would 
be too wrenching of a change.