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
