On 12/27/11, Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote: > It actually does, as per the unittests. Even if it currently does by > @property being too lax, it should continue to work.
It actually doesn't: struct FooImpl { int _x; @property int x() { return _x; } @property void x(int val) { _x = val; } auto dup() { return FooImpl(); } auto dispose() { } } void main() { RefCounted!FooImpl foo; foo.x = 1; // NG } Sure you could make a property return ref, but that's circumventing the setter and allowing direct access to the field from client-code. I've ran into this issue before when playing with opDispatch but I couldn't figure out a workaround. > >> or opBinary, > > Should work, as operators are just translated to regular methods. > >> or >> opOpAssign. > > Should work. > Doesn't seem to work: struct FooImpl { auto opBinary(string op)(int val) { return this; } void opOpAssign(string op)(int val) { } auto dup() { return FooImpl(); } auto dispose() { } } void main() { RefCounted!FooImpl foo; auto f = foo + 1; // ng foo += 1; // ng } > So construction of objects > needs to be handled by RefCounted itself - e.g. by forwarding > constructor parameters. But it doesn't do that currently?