On Wednesday, 5 February 2014 at 09:05:02 UTC, Adam Wilson wrote:
On Tue, 04 Feb 2014 23:38:54 -0800, Kagamin <[email protected]>
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.
They have done it.
It is how the systems programming language Cedar, for the Mesa
operating system at Xerox PARC used to work.
There are papers about it, that I already posted multiple times.
--
Paulo
