[dmd-beta] D 2.059 beta 3

[Alex Rønne Petersen]

> 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 <jmdavisProg at gmx.com> wrote:
> On Monday, April 09, 2012 10:26:37 kenji hara wrote:
>> 2012年4月9日10:07 Jonathan M Davis <jmdavisProg at gmx.com>:
>> > 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
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta