draft proposal for ref counting in D

[Walter Bright]

Steven Schveighoffer wrote:
On Jun 30, 2013, at 10:08 PM, Michel Fortin wrote:

 > Le 30-juin-2013 à 20:25, Steven Schveighoffer a écrit :
 >> I don't think this is that bad.  iOS on ARM which has terrible atomic 
primitives uses atomic reference counts.
 >
 > Moreover iOS uses a single spinlock to protect a global hash table containing 
all reference counts.

Hearing this, I actually find it amazing how well it works :)

 >> If you do NOT involve the GC and are careful about cycles, then you could 
potentially have a RC solution that does not require atomics.  But that would 
have to be a special case, with the danger of having cycles.
 >
 > Not involving the GC is quite difficult: you need to be absolutely sure you 
have no pointer pointing to that thread-local ref-counted object anywhere in the 
GC-heap. Unfortunately, there's no way to guaranty statically what is part of 
the GC heap and what is not, so any non-atomic reference counter is not @safe.

This is true, I was thinking of garbage collected RC object referring to RC 
object, I wasn't thinking of fully GC object referring to RC object.

In terms of pure functions and possibly a @nogc attribute, this might be a 
possibility.  Maybe at some point we have a @nogcref attribute we attach to 
specific *types* so the compiler prevents you from storing any references to 
that type in the GC.

I think it is be important to reserve the possibility for having cases where RC 
inc/dec is not atomic.  Especially where we have D's type system identifying 
what is shared and what is not.  Especially when there is the possibility for 
thread-local GCs.

-Steve