How will we fix opEquals?

[Don]

Michel Fortin wrote:
> On 2011-02-10 15:22:48 -0500, Don <nospam at nospam.com> said:
> 
>> Steven Schveighoffer wrote:
>>> This doesn't work.  If you only define one, then you will have 
>>> problems with hidden function errors, and/or inconsistencies.  For 
>>> example, how does .opEquals(Object obj1, Object obj2) know which 
>>> version to call?
>>>
>>> I think the only true solution is to make it const and call it a day.
>>>
>>> -Steve
>>
>> I fear that you're probably right. The const opEquals must exist, 
>> otherwise the object will be unable to use most functions in Phobos.
>> And I don't see how it can safely be synthesised from non-const opEquals.
>>
>> A tiny compromise which could be made, is to silently add 'const' to 
>> any class opEquals declaration, even if not present in the source. 
>> That way, simple use cases would still compile without complaint.
>> (As long as only a single, precisely defined opEquals signature is 
>> permitted, I think any other signature should be flagged as an error 
>> -- but it could be converted to the correct signature, instead).
> 
> I don't like this idea at all. If the problem is that it's too easy to 
> hide the underlying function without noticing (no compile-time error), 
> then fix how the language treats hidden functions (make it a 
> compile-time error). If opEquals has this problem, other 
> non-language-defined functions will have it too, and fixing it with a 
> special case for opEquals will not fix it elsewhere. Not to speak of the 
> inconsistency it adds.
> 

Oh, I agree. I don't think it's a good idea. It's just the _only_ 
compromise I could see that would actually work.