DIP74: Reference Counted Class Objects

[Taylor Hillegeist via Digitalmars-d]

On Sunday, 1 March 2015 at 13:13:58 UTC, bearophile wrote:
> Jacob Carlborg:
>
>> @arc class Foo
>> {
>>    T1 opAddRef();
>>    T2 opRelease();
>> }
>> ...
>> Alternative A gives a clear documentation it's a reference 
>> counted class without having to scan the methods.
>
> Assuming you want something like DIP74, this design design 
> seems safer than the design proposed in DIP74.
>
> Bye,
> bearophile

So, I don't know a huge amount about this subject. aka. (hold my 
beer) but I do know that seemingly by default D has garbage 
collection which is wonderful... but It is also wonderful to have 
choices.

I see a story like the tortoise and the hare.  Where the garbage 
collector is like the hare, going really fast but then taking a 
break. Reference counting is like the tortoise, a bit slower but 
more predictable.

It is clear Reference counting takes more discipline, but unclear 
to me how D will help/guide its users through process. it seems 
like the @safe will disallow some obviously dumb things. which is 
actually really awesome.

It is also unclear how combining both RC and GC will work, how 
does the GC know not to scan the RC's territory?  And if it does 
is it actually beneficial to have RC?

As far as DIP74: In the Definition I am confused what UFCS has to 
do with defining the opAddRef() and opRelease() methods. And also 
why the are used in the fun() x.opAddref() example. I probably 
have like 100 more dumb questions but lets leave it there. :D