Escaping the Tyranny of the GC: std.rcstring, first blood

[Manu via Digitalmars-d]

On 25 September 2014 07:17, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 9/24/14, 1:15 PM, Manu via Digitalmars-d wrote:
>>
>> Something like (whatever syntax you like):
>>
>> int^ rcInt; // refcounted pointer to an int
>> MyStruct^ rcStruct; // refcounted pointer to a struct
>> MyStruct s; // normal value-type struct, but if the struct has
>> opInc/opDec, the RC handling code in the compiler can implicitly
>> generate calls to opInc/opDec on assignment, which will allow the
>> struct to manage itself.
>
>
> You're getting confused here, postblit and destructor take care of that.

No they don't. It's not a ref counting mechanism, the compiler can't
elide those calls.
It's what I use now, and it's as good at C++, but we can do much
better than that.


>> Not sure how to express an RC dynamic array... int[^] rcArray? Anyway,
>> syntax is whatever it is, I think this approach is what makes sense to
>> me though.
>
>
> Whatever syntax I like? Awesome! How about:
>
> RefCounted!int rcInt; // refcounted pointer to an int
> RefCounted!MyStruct rcStruct; // refcounted pointer to a struct
> RefCounted!(int[]) rcArray; // refcounted array
>
> The irony is the first two already work with the semantics you need, but
> apparently I've had difficulty convincing you to try them and report back.
> My work on RCString has also gone ignored by you, although it's exactly
> stuff that you're asking for.

It all feels backwards to me. You've completely alienated me from the
discussion. I've given up, but I am watching with interest.

I'm not interested in a library solution until I know if, and how the
compiler will optimise it... in which case it's not a library solution
anymore, so why make the implementation a lib?
@nogc users will use this stuff EXCLUSIVELY. There is already more
than enough attribution in D, I *WILL NOT* wrap everything in my
program with RefCounted!(). I will continue to invent my own solutions
in every instance, and we will live the same reality as C++; where
everyone has their own implementations, and none of them are
compatible.

Call it a bikeshed, whatever. I'm certain this is the practical reality.

I have tried RefCounted extensively in the past. Mangling my types
like that caused lots of problems, heaps of is(T == RefCounted!U, U)
started appearing throughout my code, and incompatibility with
existing libraries.
Perhaps the most annoying thing about a library implementation though
is the debuginfo baggage. It's extremely frustrating dealing with
things that are wrapped up like RefCounted while debugging. You can't
evaluate the thing anymore, stepping through your code leads you
through countless library stubs and indirections. You lose the ability
to just read a symbol name without fuss, you need to make your
callstack window half the screen wide to see what you're looking at.

I'm also not convinced meaningful refcounting can be implemented
before we have scope(T) working properly. I think we should be
addressing that first.