Prototype of Ownership/Borrowing System for D
newshound2 at digitalmars.com
Wed Nov 20 22:45:05 UTC 2019
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
> 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.
More information about the Digitalmars-d