[phobos] [D-Programming-Language/phobos] 601c75: Improve parsing error handling

[Andrei Alexandrescu]

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<jmdavisProg at gmx.com>:
>> 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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos