> 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. Regards, Alex On Mon, Apr 9, 2012 at 3:33 AM, Jonathan M Davis <[email protected]> wrote: > On Monday, April 09, 2012 10:26:37 kenji hara wrote: >> 2012年4月9日10:07 Jonathan M Davis <[email protected]>: >> > There really should be errors for opEquals, opCmp, toString, and toHash >> > with incorrect signatures, >> >> It is difficult to detect *incorrect signatures*, because compiler >> cannot judge it is a mistake of programmer, or is intended one of him. > > 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. > >> > and for any of them that need multiple overloads, it >> > should complain not only if any of the overloads are incorrect but if any >> > are missing. The fact that it's sort that's complaining makes it very >> > hard to determine what's actually wrong. >> >> At least, we should fix const system holes (e.g bug1824 - Object not >> const correct) before adding this kind of enforcements. Otherwise >> compiler may block some user codes that picks the const system holes >> but works as expected. > > We should enforce whatever is currently required by the compiler. That > enforcement can change when the requirements change. For instance, if a > struct's opEquals must currently look like > > bool opEquals(const S rhs) const {} > bool opEquals(const ref S rhs) const {} > > then it should be an error if it doesn't. And if the requirements change so > that a struct's opEquals should look like > > bool opEquals(const S rhs) @safe const pure nothrow {} > bool opEquals(const ref S rhs) @safe const pure nothrow {} > > then at that point, it'll complain if they don't look like that. Right now, > the compiler is requiring things for these functions but not always giving > errors when stuff doesn't match (or good ones when it does give errors), > making > it hard to get it right. > > Obviously, the compiler can't require that all of these functions look like > they're going to look a release or two from now, since that's going to change > as we iron things out to make it possible for them to have the signatures that > we want, but since the compiler _does_ have requirements for them (even if > they're incomplete compared to what they will be), I don't see why the > compiler shouldn't be complaining if they don't match what it currently > requires. > > - Jonathan M Davis > _______________________________________________ > dmd-beta mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-beta _______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
