"Thiez" , dans le message (digitalmars.D:172060), a écrit : >>> Have you considered adding operator overloading using UFCS >>> while you're at it? >> >> I assumed it's already possible to add operators >> non-intrusively, because operators are just syntactic sugar for >> method calls: >> >> ++var; // actual code >> var.opUnary!"++"(); // lowered once >> opUnary!"++"(var); // lowered twice (if necessary) >> >> If you're talking about overloading existing operators (which >> have been implemented as member functions) non-intrusively for >> other types, then I don't know, doesn't it work? > > I actually tried those yesterday (with opEquals and opCmp on > structs) and couldn't get it to work. Code still used what > appeared to be an automatically generated opEquals (that appears > to perform a bitwise comparison) instead of my UFCS opEquals.
This behavior for opEquals is debatable, but make sense. If the designer of a struct did not implement opEquals, it may be that he intended opEqual to be the default opEqual. If you overload opEquals for such struct, you may be hijacking it's intended behavior: your not just adding a functionality, your overriding an existing functionality. Did you try operators that are not automatically generated ? > It's already quite obvious that the compiler does not obey its > own rewrite rules (see > http://dlang.org/operatoroverloading.html#compare) Consider opCmp: > a < b > is rewritten to > a.opCmp(b) < 0 > or > b.opCmp(a) > 0 > Let's assume the first rule is always chosen. According to the > very rewrite rule we just applied, this must be rewritten to > a.opCmp(b).opCmp(0) < 0 > > It seems quite obvious the compiler does not rewrite compares on > integers or all hell would break loose... The language reference > should be more specific about these things. The rewrite rule obviously apply only if the comparison operator is not already defined for those types by the langage. That could be precised in the web site, but it's consistent. By the way, would it be possible to implement an opCmp that returns a double, to allow it to return a NaN ? That may allow to create values that are neither superior, nor inferior to other value, like NaNs. It's not possible to implement opCmp for a floating point comparison if opCmp is bound to return an int. Another reason to ban Object imposing a specific signature for opCmp in all classes...
