Idea #1 on integrating RC with GC

[Adam Wilson]

On Tue, 04 Feb 2014 23:38:54 -0800, Kagamin <spam at here.lot> wrote:

> My understanding was that ARC completely replaces GC and everything  
> including slices becomes refcounted. Is having mixed incompatible GC and  
> ARC code and trying to get them interoperate a good idea? Can you sell  
> such mixed code to ARC guys?

I've been asking myself those questions a lot over the past couple days.  
If GC backed ARC is such a brilliant idea, how come nobody has done it  
yet? I mean, it is a rather obvious solution. What I am confident of is  
that it is going to create a metric-ton of implementation gotchas for the  
compiler to sort out (as if we don't have enough open trouble tickets  
already) and it is going to pretty steeply increase the complexity of  
language. I thought the whole point of D was to not be C++, particularly  
in terms of complexity? All for a potentially undeliverable promise of a  
little more speed and fewer (not none) collection pauses.

I have a suspicion that the reason that it hasn't been done is that it  
doesn't actually improve the overall speed and quite possibly reduces it.  
It will take months of engineering effort just to ship the buggy initial  
functionality, and many more months and possibly years to sort out all the  
edge cases. This will in turn significantly reduce the bandwidth going  
towards fixing the features we already have that don't work right and  
improving the GC so that it isn't such an eyesore.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator