On Tue, 13 Oct 2009 00:31:32 -0400, dsimcha <[email protected]> wrote:
It seems that D's operator overloading is a bit silly in some cases
w.r.t.
opAddAssign, opSubAssign, etc. Consider the following example:
struct Foo {
Foo opAdd(Foo rhs) {
return this;
}
}
void main() {
Foo foo;
Foo bar;
foo = foo + bar; // Works.
foo += bar; // Doesn't work.
}
I'm thinking (not sure if this was proposed here before a while back and
I
just forgot where I heard it from) that the default behavior of
someObject.opXAssign(otherStuff); should be to expand into someObject =
someObject.opX(otherStuff); if opXAssign is not overloaded. Besides the
programmer being too lazy to explicitly overload opXAssign, I just found
another use case.
Suppose you have a bunch of classes and you're overloading operators
such that
each call builds another layer of decorators. For example:
class SomeClass {
SomeClass opAdd(SomeClass rhs) {
// SomeDecorator is a subclass of SomeClass.
return new SomeDecorator(this, rhs);
}
}
In this case, you *can't* overload SomeClass.opAddAssign in any
reasonable way
because you can't assign SomeDecorator to this, but translating
someInstance.opAddAssign(someOtherInstance) into someInstance =
someInstance.opAdd(someOtherInstance) makes perfect sense.
Also, if you template both opX and opX_r you will always get a overload
conflict.
