[dmd-beta] D 2.059 beta 3

[Jonathan M Davis]

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