How will we fix opEquals?

[Michel Fortin]

On 2011-02-10 04:36:56 -0500, Don <nospam at nospam.com> said:

> 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.
> Can you think of a use case where the calling function should know that 
> opEquals() isn't truly const?

If you use casts on some member variables, make sure the member is 
marked shared don't forget to cast to shared mutable, not just mutable, 
because you never know when your immutable object is shared between 
threads. Suggesting casts looks error prone to me, but it can probably 
work.

To answer the original question, yes opCmp, opEquals, toHash, toString 
should all be const. Otherwise it makes it impossible to use 
const/immutable objects in any generic code requiring those functions 
to be available. And generic code will otherwise work perfectly fine 
with non-mutable objects once Walter merges my const(Object)ref patch 
in the mainline.

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