How will we fix opEquals?

[Michel Fortin]

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.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/