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