Reference counted containers prototype

[Andrei Alexandrescu]

On 12/26/11 8:23 PM, Peter Alexander wrote:
> On 27/12/11 1:29 AM, Andrei Alexandrescu wrote:
>> We can easily have opDispatch look at field names. But I think it's poor
>> design to expose bald data anyway.
>
> I disagree, especially with immutable structs. There's no point wrapping
> immutable data in functions or properties.

Good point. It can be done.

Embedded type aliases are more of a problem, but still doable. For 
example say DListImpl defines a type DListImpl!(T).Range inside - that 
should be accessible also as DList!(T).Range.

>>> Also, what about template member functions of the held object?
>>>
>>> struct Foo
>>> {
>>> int get(int X)() { return X; }
>>> }
>>>
>>> void main()
>>> {
>>> RefCounted!Foo f;
>>> writeln(f.get!123()); // Doesn't work either
>>> }
>>
>> This is a problem.
>
> I would recommend postponing any major additions to Phobos that use
> opDispatch to forward calls until it has been investigated in full.

We're a long way from adding to Phobos, so no need to worry.

> I am
> not convinced that it can be used seamlessly without some relatively
> large changes to the language.

I repeat that opDispatch and auto ref were invented for this, so 
anything that doesn't work now is a bug. There are no changes needed to 
the language, only fix the bugs :o).

> Another potential problem of the top of my head: what about operator
> overloads on the held object? Just forward from opUnary/opBinary etc.?

Will work.

> What about held objects that overload opAssign?

Already works.

> What if the held object is itself a RefCounted?

Well I'd say it should all work as expected!


Andrei