Mac Apps That Use Garbage Collection Must Move to ARC

[Johannes Pfau via Digitalmars-d]

Am Thu, 26 Feb 2015 01:55:14 +1000
schrieb Manu via Digitalmars-d <digitalmars-d at puremagic.com>:

> >> I agree. I would suggest if ARC were proven possible, we would
> >> like, switch.
> >>  
> >
> > I'd like to see ARC support in D, but I do not think it makes sense
> > as a default.  
> 
> Then we will have 2 distinct worlds. There will be 2 kinds of D code,
> and they will be incompatible... I think that's worse.

Excuse my ignorance, but I'm no longer sure what everybody in this
thread is actually arguing about:

Andrei's WIP DIP74 [1] adds compiler-recognized AddRef/Release calls to
classes. The compiler will _automatically_ call these. Of course the
compiler can then also detect and optimize dead AddRef/Release pairs.

All the exception issues Walter described also apply here and they also
apply for structs with destructors in general.

So I'd say DIP74 is basically ARC. Ironically structs which are better
for RC right now won't benefit from optimizations. However, it'd be
simple to also recognize Release/AddRef in structs to gain the
necessary information for optimization. It's not even necessary to call
these automatically, they can be called manually from struct dtor as
usual.

So what exactly is the difference between ARC and DIP74? Simply that
it's not the default memory management method? I do understand that
this makes a huge difference in practice, OTOH switching all D classes
to ARC seems very unrealistic as it could break code in subtle ways
(cycles).

But even if one wants ARC as a default, DIP74 is a huge step forward.
If library maintainers are convinced that ARC works well it will become
a quasi-default. I'd expect most game-related libraries (SFMLD,
derelict) will switch to RC classes.

[1] http://wiki.dlang.org/DIP74