digitalmars.D - Inconsistency increasing
- DavidL (17/17) Aug 26 2007 opAdd_r VS opAdd
- Jarrett Billingsley (10/25) Aug 26 2007 This is already defined. See
opAdd_r VS opAdd opImpicitCastTo VS opImplicitCastFrom consider: objectA + objectB objectB get opAdd_r objectA get opAdd what would happen? structB = structA structA get opImplicitCastTo and structB get opImplicitCastFrom, what would happen? both get called? or the one *well* defined by compiler( this kind of specification could cause many issues imo) we don't need an OOP style operator overloading we need a global operator overloading -- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Aug 26 2007
"DavidL" <Davidl 126.com> wrote in message news:op.txn9lnubbag506 39eee18d1a25413...opAdd_r VS opAdd opImpicitCastTo VS opImplicitCastFrom consider: objectA + objectB objectB get opAdd_r objectA get opAdd what would happen?This is already defined. See http://www.digitalmars.com/d/1.0/operatoroverloading.html, Binary Operator Overloading, example 5. This is ambiguous.structB = structA structA get opImplicitCastTo and structB get opImplicitCastFrom, what would happen? both get called? or the one *well* defined by compiler( this kind of specification could cause many issues imo)This would probably result in a similar ambiguosity.we don't need an OOP style operator overloading we need a global operator overloadingIf it's well-defined (which it is), OOP-style operator overloading works just fine. However, notice that D2 is generalizing method calls, so that "x.f()" and "f(x)" can be semantically equivalent. This might bring global operator overloading as a side-effect.
Aug 26 2007