Argh! This is quickly becoming the release from hell. I've gotten it to *compile* my code without warnings, but now my struct no longer works right when used as an AA key...

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

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

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
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

I entirely agree that it would be nice if the compiler warns for all wrong signatures of overloaded operators. But since it currently does allow arbitrary signatures (and calling them as normal functions), I think consistency is more important. I'm all for moving to a system where the compiler emits warnings for these cases, but let's do it properly and not just for some specific operator overloads.

Regards,
Alex

On Mon, Apr 9, 2012 at 11:33 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> 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
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

I disagree. 2.059 contains a breaking change that appears to be causing several issues. Walter believes that C code should either compile and work or be a compile error; I think we should apply the same logic to 2.059. If an operator overload was accepted as such in 2.058 but won't be in 2.059 then it must be an error. Generalization can come later.

Sent from my iPhone

On Apr 9, 2012, at 5:52 AM, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> I entirely agree that it would be nice if the compiler warns for all wrong signatures of overloaded operators. But since it currently does allow arbitrary signatures (and calling them as normal functions), I think consistency is more important. I'm all for moving to a system where the compiler emits warnings for these cases, but let's do it properly and not just for some specific operator overloads.
> 
> Regards,
> Alex
> 
> On Mon, Apr 9, 2012 at 11:33 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>> 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
>> dmd-beta@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

From: "Nick Sabalausky" <bus_dmdbeta@semitwist.com>
>
> Argh! This is quickly becoming the release from hell. I've gotten it to *compile* my code without warnings, but now my struct no longer works right when used as an AA key...

This issue went away when I fixed my code to have *both* the ref and non-ref overloads of opCmp/opEquals/etc.

Everything seems to be working for me now, aside from #7833, which is just a documentation matter.

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Monday, April 09, 2012 23:51:00 Nick Sabalausky wrote:
> This issue went away when I fixed my code to have *both* the ref and non-ref overloads of opCmp/opEquals/etc.

Yeah, it's looking like both of those overloads will be required for pretty much any function which has an overload which takes const ref as long as auto ref doesn't work with non-templated functions. And if auto ref never ends up working with non-templated functions, then we're going to have to be duplicating const ref functions as a matter of course. It's just highlighted by the fact that opEquals and opCmp are so prominent.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta