On Tue, 04 Feb 2014 16:07:29 -0800, Adam Wilson <[email protected]> wrote:
On Tue, 04 Feb 2014 15:51:35 -0800, Andrei Alexandrescu
<[email protected]> wrote:
Consider we add a library slice type called RCSlice!T. It would have
the same primitives as T[] but would use reference counting through and
through. When the last reference count is gone, the buffer underlying
the slice is freed. The underlying allocator will be the GC allocator.
Now, what if someone doesn't care about the whole RC thing and aims at
convenience? There would be a method .toGC that just detaches the slice
and disables the reference counter (e.g. by setting it to uint.max/2 or
whatever).
Then people who want reference counting say
auto x = fun();
and those who don't care say:
auto x = fun().toGC();
Destroy.
Andrei
I am assuming that you ignoring cyclic-refs for now. And dealing with
them would mean that you would need something like:
auto @weak x = fun();
Since the compiler cannot figure out that this is supposed to be weak or
not it would assume strong as that is the majority.
Second thought. Why is their an extra step for those of us who don't
want the GC. I know there has to be an extra step for some people, but I
feel that we should make the simplest option the default and then open
up avenues for more advanced control for people who want it. ARC is not
as simple to understand as a GC for newbies, and ARC requires more
careful control, so why not make getting into ARC a little harder, that
way we prevent heartache for new people. So something more like:
auto x = fun().toARC();
I can't imagine any situation where you could go from ARC to GC that
could not also go from GC to ARC, they have to be equivalent operations
to do that anyways.
In the design world you make the simple option easy and more the more
advanced options harder to get at to reduce the chance that the user
accidentally shoot themselves in the foot. And the guys who want to the
advanced options are power users anyways, they expect to have to work at
it a little more.
Related third thought. This goes against the current paradigm and will
subtly break existing D code that has cyclic-refs in it.
Ok, disregard my previous post. I think I understand better what Andrei is
driving at, but it's not obvious, better examples are needed. But more to
the point this is going to make us all equally miserable. The ARC guys
don't get the compiler support needed to make ARC fast. It completely
ignores cyclic-refs inside the slice. It doesn't solve the primary
ARC-camp complaint about the reliance on the GC. The GC now guys have more
hoops to jump-through when working with Phobos. And it increases
complexity and cognitive load all around.
--
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
