Why struct opEquals must be const?

[Pelle]

On 10/18/2010 05:07 PM, Steven Schveighoffer wrote:
> On Mon, 18 Oct 2010 10:49:25 -0400, Pelle <pelle.mansson at gmail.com> wrote:
>
>> Shouldn't the compiler make the opEquals non-const if one of the
>> struct members requires mutability for equality testing? Just a thought.
>
> IMO, opEquals should allow non-const, but only if the type is a value
> type (no references). This means opEquals on a class should always be
> const.
>
> Allowing opEquals to modify the original object violates the expectation
> of opEquals -- you don't expect comparison to change the objects being
> compared.
>
> But logically, opEquals shouldn't require any specific signature -- it's
> just another function.
>
> What case were you thinking of for requiring mutablity for equality
> testing?
>
> -Steve

I was thinking along the lines of not enforcing unexpected restrictions 
on programmers because we couldn't think of a use case. This isn't an 
enabler.

Today, the check isn't very intelligent, which makes immutable structs 
unusable.