On 2/5/14, 12:23 PM, Michel Fortin 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.
I want to make one positive step toward improving memory allocation in
the D language.
Andrei
