This remains a bug in the compiler. One opEquals signature should
suffice, namely:
bool opEquals(const S rhs) const;
If someone wants to optimize away a copy when an lvalue is in the rhs
position, they could add the overload:
bool opEquals(ref const S rhs) const;
But the second should be optional.
One more thing - the compiler should _not_ require these signatures. It
should let the user define them as they wish and simply limit itself to
translating a == b to a.opEquals(b).
Andrei
On 9/5/11 6:31 AM, kenji hara wrote:
2011/9/5 Jonathan M Davis<[email protected]>:
On Monday, September 05, 2011 11:20:57 Don Clugston wrote:
I've never been able to get that to work. Although you can get those
two to work, it fails in other cases. Eg, as in the code below.
Have you been able to do this successfully?
[snip]
Probably not. I don't think that I've tried though. I'm not sure how often
I've used immutable structs in a context that ended up using an equality
check.
Regardless, opEquals obviously needs to be sorted out. You shouldn't need two
definitions like that to get it to work even if they did work in all cases.
I think we need to define tow opEquals, const bool opEquals(const S
rhs) and const bool opEquals(const ref S rhs).
But rvalue version is automatically builded by compiler, like follows:
const bool opEquals(const S rhs) {
return this.opEquals(rhs); // run lvalue version
}
So we don't need to *write* two opEquals still.
Kenji Hara
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
