Idea #1 on integrating RC with GC

[Michel Fortin]

On 2014-02-05 18:26:38 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 2/5/14, 7:23 AM, Michel Fortin wrote:
>> I don't think it makes much sense. ARC when used for D constructs should
>> be treated an alternate GC algorithm, not a different kind of pointer.
> 
> Why? The RC object has a different layout, so it may as well have a 
> different type.

Well, it depends on your goal. If your goal is to avoid the garbage 
collector, you need all language constructs to use ARC. Having a single 
type in the language that relies on the GC defeats the purpose. What 
you want is simply to replace the current GC with another implantation, 
one that uses ARC. It shouldn't affect user code in any way, it's 
mostly an implementation detail (managed by the compiler and the 
runtime).

If your goal is to have a deterministic lifetime for slices in some 
situations, then RCSlice as you proposes it is fine. That said, with a 
library type you'll have a hard time making the optimizer elide 
redundant increment/decrement pairs, so it'll never be optimal. I'm 
also not sure there's a lot of use cases for a deterministic slice 
lifetime working side by side with memory managed by the current GC.

To me it seems you're trying to address a third problem here: that 
people have complained that Phobos relies on the GC too much. This 
comes from people who either don't want the GC to pause anything, or 
people who want to reduce memory allocations altogether. For the former 
group, replacing the current GC with an ARC+GC scheme at the language 
level, with the possibility to disable the GC, will fix most of Phobos 
(and most other libraries) with no code change required. For the later 
group, you need to make the API so that allocations are either not 
necessary, or when necessary provide a way to use a custom an allocator 
of some sort.


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca