March 10, 2010 [dmd-internals] where is opAssign? | ||||
---|---|---|---|---|
| ||||
I had a look at the new operator overloading and I can't seem to find opAssign in opover.c. http://www.digitalmars.com/d/2.0/operatoroverloading.html#Assignment Seems like what I reported in the newsgroups (along with some other potential bugs) is indeed a bug or the specs aren't up-to-date. Vector2f _pos = Vector2f(0.f, 0.f); gets rewritten as _pos.opBinary!("=")(...) On March 8, 2010 20:01 Uhr, Trass3r wrote: > Guess it's better to post this here. Are these some bugs or is there another problem? > > the following code strangely yields: > dsfml\system\vector2.d(47): Error: variable > dsfml.system.vector2.Vector2!(float).Vector2.op only parameters or > foreach declarations can be ref > > /// element-wise operations, +, -, > ref Vector2 opBinary(string op)(ref Vector2 v) > { > mixin("return Vector2!(T)( cast(T)(x " ~ op ~ " v.x), cast(T)(y > " ~ op ~ " v.y) );"); > } > > Removing ref from the return type makes it compile. > > > Furthermore the assignment operator seems to be rewritten as opBinary instead of opAssign as the docs state: > > Vector2f _pos = Vector2f(0.f, 0.f); > yields: > Error: template instance opBinary!("=") matches more than one template > declaration > > > This also shows another problem. It can't distinguish between these two: > Vector2 opBinary(string op)(ref Vector2 v) > if (op != "*") > { > mixin("return Vector2!(T)( cast(T)(x " ~ op ~ " v.x), cast(T)(y > " ~ op ~ " v.y) );"); > } > > Vector2 opBinary(string op)(int i) > { > mixin("return Vector2!(T) ( cast(T)(x " ~ op ~ " i), cast(T)(y " > ~ op ~ " i) );"); > } > > even though vec1 + vec2 resp. vec + 5 is unambiguous. |
March 12, 2010 [dmd-internals] where is opAssign? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Trass3r | > I had a look at the new operator overloading and I can't seem to find opAssign in opover.c. http://www.digitalmars.com/d/2.0/operatoroverloading.html#Assignment > Ok, found it. I guess writing "if (!s && !s_r && op != TOKequal && op != TOKnotequal && op != TOKassign)" in opover.c:458 should prevent this bug: http://d.puremagic.com/issues/show_bug.cgi?id=3935 The only question is if this is intended. Should opAssign stay or should it be opBinary!("=")? Furthermore, where are the checks that are suggested by http://www.digitalmars.com/d/2.0/operatoroverloading.html#Assignment The following compiles even though opAssign(T) isn't allowed "where T is the same type as the aggregate type A" struct Foo { void opAssign(Foo f) { } } void main() { Foo f; f = f; } The only implemented check I could find is the following from AssignExp::semantic, line 8931 but this one is only for classes. else if (t1->ty == Tclass) { // Disallow assignment operator overloads for same type if (!e2->type->implicitConvTo(e1->type)) { Expression *e = op_overload(sc); if (e) return e; } } |
Copyright © 1999-2021 by the D Language Foundation