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

[Manu via Digitalmars-d]

On 25 September 2014 00:55, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 9/24/14, 3:31 AM, Dmitry Olshansky wrote:
>>
>> 23-Sep-2014 19:13, Andrei Alexandrescu пишет:
>>>
>>> On 9/23/14, 12:17 AM, Dmitry Olshansky wrote:
>>>>
>>>> In my imagination it would be along the lines of
>>>> @ARC
>>>> struct MyCountedStuff{ void opInc(); void opDec(); }
>>>
>>>
>>> So that would be a pointer type or a value type? Is there copy on write
>>> somewhere? -- Andrei
>>
>>
>> It would be an intrusively counted type with pointer somewhere in the
>> body. To put it simply MyCountedStuff is a kind of smart pointer.
>
>
> Then that would be confusing seeing as structs are value types. What you're
> saying is that a struct with opInc() and opDec() has pointer semantics
> whereas one with not has value semantics. That design isn't going to fly.

I think the way I imagine refcounting is the opposite of what you're
saying here.

RC would be a type of pointer. An RC struct pointer can be handled
implicitly without problem.
That said, it's potentially very useful to support RC value types too,
and the way to do that would be for the struct to have opInc/opDec. In
that event, the compiler can generate calls to those operators on
assignment.

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.

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.