draft proposal for ref counting in D - BRIEF ROUNDUP

[deadalnix]

On Saturday, 12 October 2013 at 14:03:26 UTC, Sönke Ludwig wrote:
> I've made short roundup of the different features/requirements 
> that have been mentioned (may have forgotten some and added 
> some) as this thread has a complexity that presumably makes it 
> quite hard to follow for most readers. I have also attached an 
> estimated priority for each requirement based on the discussion 
> and my own experiences.
>
>  - Memory safety [very important but also very 
> difficult/limiting]
>      Disallow escaping uncounted references to reference counted
>      memory. Keywords: pure, scope, isolated/owned

We have a first missing block here :D

I do think this is mandatory.

>  - Objective-C compatible [important]
>      Weak references, manual memory management and autorelease 
> pools are
>      some keywords here

Can someone explain me what an autorelease pool is ?

>  - Handle reference cycles [nice to have]
>      Requires GC memory for storing the instances

The good new is that we can (and IMO should) layer ref counting 
on top of GC. This is the only way to make both work nicely 
together and have safety net for leakage.

>  - Weak pointers [critical]
>      Only briefly mentioned, but critical for many data 
> structures
>      (e.g. graphs or caches) requires external reference 
> counting

Easy for RefCounted but become tricky for GC stuff.

>  - Not require two separate counts for COM [mildly important]
>      Using GC memory would require a second reference count for 
> the
>      D side of things, which is not desirable for multiple 
> reasons

Can you explain that one a bit more ? Especially how it require 2 
count.

>  - Support type qualifiers [critical]
>      All usual type qualifiers and conversions should work as 
> expected.
>      This is not possible in a pure template based solution.

Here we have the second piece missing. We need a way to tail 
qualify template.

>  - Not require new annotations [important]
>      Getting this to work without introducing new 
> keywords/syntax is
>      strongly preferred by Walter

We have 2 missing bloc to make that work (from a language 
perpective, many runtime/compiler magic is also required).

>  - Support OOP reasonably well [important]
>      The usual up and down casts should work and calling 
> functions of
>      base classes needs to be safe
>

I see no way to make that work without increasing the scope of 
scope (huhuhu :P)

> Please mention any points that I have forgotten so that we have 
> some kind of unit test against which proposed designs can be 
> checked.

You did an excellent job here. I guess we have 2 missing piece 
(and an incomplete one in the name of scope) to get sorted out 
and we can get something really nice here !