opAssign() still accepted for classes???
Steven Schveighoffer
schveiguy at yahoo.com
Fri Apr 29 09:36:42 PDT 2011
On Fri, 29 Apr 2011 12:25:40 -0400, Alexander <aldem+dmars at nk7.net> wrote:
> On 29.04.2011 18:13, Steven Schveighoffer wrote:
>
>> Static opCall is possible, but I wasn't aware of the other operator
>> overloads being possible.
>
> I wasn't too - it is not mentioned anywhere, just tried it.
>
>> Note that opAssign is a valid symbol name, so it can be used in places
>> even where it doesn't overload assignment, such as a static or global
>> function. It just won't map to any operator usage.
>
> Well, the fact is - it maps. If I've static opAssign() defined, it is
> called when I assign something to an object.
>
> Even more fun - static opAdd() maps too, and - wow! - if it returns
> new object, i.e. construction like:
>
> X x;
> x = x + 3;
>
> then it will allocate new instance of X, where: static typeof(this)
> opAdd(int i) { return new X(i); }
>
> I am impressed... :)
That most certainly is a bug.
What I think is happening is you can call static functions with an
instance of that type, but the instance isn't passed to it, it's just used
as a namespace. This is a "feature" that I continue to feel is a bug.
So for example, you might expect:
x = new X(4);
x = x + 3;
assert(x.value == 7)
but it will fail, because:
x.opAdd(3)
doesn't actually pass x into the function! So there is no way you could
possibly know what the left hand side of the operator is!
-Steve
More information about the Digitalmars-d
mailing list