Prototype of Ownership/Borrowing System for D

[Walter Bright]

On 11/20/2019 4:16 AM, Timon Gehr wrote:
> - What do you want to achieve with borrowing/ownership in D?

I want to prevent the following common issues with pointer code:

1. use after free
2. neglecting to free
3. double free

4. safe casting to immutable
5. safe conversion to/from a shared pointer


> - What can already be done with @live? (Ideally with runnable code examples.)

The test cases included with the PR should give an idea.


> - How will I write a compiler-checked memory safe program that uses varied 
> allocation strategies, including plain malloc,

I'm not sure what clarification you want about plain malloc/free, although there 
are limitations outlined in ob.md.

> tracing GC

I don't see any value OB adds to tracing GC. A GC is an entirely different solution.

> and reference counting?

The main difficulty (as you pointed out) with RC is holding on to an interior 
pointer via one reference while another reference free's what it's pointing to.
There's been a lot of progress with this with the addition of DIP25, DIP1000, 
and DIP1012. This further improves it by making the protections transitive.


> Right now, the only use I can see for @live is as an incomplete and unsound 
> linting tool in @system code.

The unsoundness is in dealing with thrown exceptions, which I have some ideas on 
how to deal with, and conflating different allocators, which I don't have a good 
idea on.

> It doesn't make @safe code any more expressive. To 
> me, added expressiveness in @safe code is the whole point of a borrowing scheme.

Technically, @live works by adding restrictions, not expressiveness.