On 6 February 2014 06:23, Michel Fortin <michel.for...@michelf.ca> wrote:
> On 2014-02-05 18:26:38 +0000, Andrei Alexandrescu < > seewebsiteforem...@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. This.