Why struct opEquals must be const?

[Pelle]

On 10/18/2010 02:41 PM, Steven Schveighoffer wrote:
> On Sun, 17 Oct 2010 02:57:02 -0400, Nick Sabalausky <a at a.a> wrote:
>
>> Is there a technical reason why the l- and r- values for opEquals must be
>> const? If the restriction is purely for the intuitive notion that
>> there's no
>> heisenstructs, then I have an example I think might be worth
>> consideration:
>> lazy caching.
>>
>> If comparison isn't always needed and requires a potentially expensive
>> computation that isn't likely needed otherwise (for example, a wrapper
>> for
>> string that does case-insensitive comparisons, if it's used in a
>> situation
>> that does more assigning/slicing/etc than comparing), then it may make
>> sense
>> to wait until an opEquals is called, and then compute the information and
>> cache it. But that requires mutating state and so can't be done in a
>> struct
>> opEquals.
>>
>> 'Course, if there is a technical reason for the restriction, then all
>> this
>> is moot.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=3659
>
> -Steve

Shouldn't the compiler make the opEquals non-const if one of the struct 
members requires mutability for equality testing? Just a thought.