How will we fix opEquals?

[Bruno Medeiros]

On 10/02/2011 09:36, Don wrote:
> so wrote:
>>> (1) If it is a const member function, then it will have a viral
>>> effect on all objects -- any function called by opEquals will have to
>>> be marked const.
>>
>> It doesn't look like we can solve this by switching the constness of
>> an Object.function,
>> unless we also state that every function in Object must be const and
>> accept the fact that no one would use these functions for other
>> purposes like caching, late binding etc...
>
>
> I can think of many examples where opEquals would be logically pure, but
> not formally pure, but it's harder to come up with ones where it is not
> const. I guess you can have situations where a lazily-computed hash
> value is cached in the object, to speed up comparisons, but it doesn't
> seem inappropriate for casts to be required when you're doing that.

Are you sure that such casts should be allowed? The compiler will be 
expecting opEquals to be proper const, not just logical const, and if 
it's not the code may break, even if only on some more obscure (but 
nonetheless valid) cases.
The only situation where I see where such cast would be valid, is if the 
object can ensure all lazily-computed values (well, at least those 
required for opEquals) have already been computed, and thus executing 
const opEquals() will indeed not change the object in any way.

The good news is that I suspect the fields used for 
opEquals/opCmp/opHash in any class are unlikely to be fields that are 
computed lazily. It's just a guess though, anyone have examples otherwise?

-- 
Bruno Medeiros - Software Engineer