draft proposal for ref counting in D

[Walter Bright]

On 6/26/2013 6:33 PM, Michel Fortin wrote:
 > Le 26-juin-2013 à 19:48, Walter Bright  a écrit :
 >
 >> D (like C and C++) loves to manipulate pointers. Having to call a function 
every time this is done would be a disaster. It means that people would be 
motivated to drop down to C to do the fast code, and we might as well throw in 
the towel.
 > But at the same time, having a GC that stops the world at irregular interval 
is worse for certain kind of things, games notably. It's been stated often on 
the forum that game developers prefer increasing the overhead if it prevents 
those hiccups. Making everything in D reference-counted would undoubtedly 
increase the general overhead, but it'd allow game developers to leverage the 
whole language and its libraries instead of restricting themselves to a custom 
subset of the class hierarchy derived from a reference counted class.
 >
 > And about pointer manipulation: for cases where you know for certain that the 
pointer still points to the same memory block before and after the assignment 
(when you call popFront on an array for instance), you have no reference count 
to update and can elide the call.

I've never seen a scheme for "knows for certain" that did not involve extensive 
and intrusive pointer annotations, something we very much want to avoid. Pointer 
annotations work great in theory, but in practice no successful language I know 
of uses them (we'll see if Rust will become an exception).

 >
 > The downside of optional support for language-wide reference counting is that 
it requires two incompatible codegen (or rather one incompatible with RC). We 
could have only one if it's the one that calls the retain/release functions on 
pointer assignment, with those functions replaced with empty stubs in druntime 
when reference counting is disabled, but some overhead would remain for the 
function call.
 >
 > I'm not claiming this is the right solution. It's just an idea I wanted to 
mention as an aside because it has some common points. It is however a mostly 
separate matter from your initial goal of supporting custom reference counting 
schemes for some object hierarchies. I decided to write about it mostly because 
you talked about reimplementing arrays using classes and that got me thinking. 
But perhaps I shouldn't have mentioned it because it seems to be side-tracking 
the discussion.
 >

This proposal is modeled after C++'s shared_ptr<T> in that it should have 
equivalent performance and capabilities. Since it has been well accepted into 
the C++ "best practices", I think we're on solid ground with it.