On Monday, April 09, 2012 11:26:09 Alex Rønne Petersen wrote: > > It doesn't matter what the programmer intended. If specific signatures are > > required for these functions, then the compiler knows exactly what they > > should look like, and if they don't match, then they're wrong. > > It does matter. Nothing in the D language stops you from having a > function called opEquals() with arbitrary parameter types that isn't > intended to actually overload *the* opEquas(). Therefore, as Kenji > said, the compiler can't really judge whether you actually did intend > to overload opEquals() or not.
Do you honestly think that that's an issue? Yes, someone _could_ choose to name a function opEquals without intending to invoke it as an overloaded operator, but is there _any_ reason to support that? What valid reason is there to do that, _especially_ when you consider that in 99.9999999999999999999999999999999% of the cases, if opEquals isn't able to be invoked as an overloaded operator because its signature is wrong, it's a bug, and the programmer is going to want the compiler to complain about it. Also, I don't think that the spec actually says that it _is_ legal to declare a function with the same name as an overloaded operator without having it be that overloaded operator. It _can_ happen sometimes, because the compiler tends to be picky about the signature of overloaded operators and doesn't necessarily give an error if they're wrong (though it does in some cases), but I would have fully expected that declaring a function with the same name as an overloaded operator without it overloading that operator would be illegal. However, the spec is not clear no the matter, and we're left with a situation where overloaded operators may or may not work, because their signatures aren't quite right, and the compiler doesn't always give you proper error messages about it. - Jonathan M Davis _______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
