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
