Why are opEquals/opCmp arguments not in or const for Objects?

[Stewart Gordon]

On 19/03/2013 00:46, Jonathan M Davis wrote:
> On Tuesday, March 19, 2013 00:26:40 Stewart Gordon wrote:
<snip>
>> Why can't it be used as a means of lazy initialization?
>
> Because if one of the member variables hasn't been initialized yet, then it
> can't be compared.

You miss the whole point of what I'm saying.  Why can't some result 
stored in an out-of-object cache be used as a substitute for a member 
variable?

<snip>
> There _are_ types which _can't_ have const on opEquals, because they _need_ to
> be able to mutate state in opEquals (e.g a lazily initialized object). They
> may very well be logically const, but they're not physically const.
<snip>

This lazily initialised data would be calculated from the data already 
in the object, right?  So why can't it just calculate the equality 
directly from that data?

Even if it is computationally expensive to determine whether two objects 
of a given class are equal, why does it absolutely need to put the 
intermediate data into the object?  Why can't it just use local 
variables to hold this intermediate data?  In extreme cases, even make 
mutable copies of the objects to be compared and call the non-const 
opEquals on those?

What I'm suggesting may be inefficient in complicated cases, but that's 
different from being impossible, which is what you're basically saying.

Moreover, all this talk seems hypothetical.  I'm yet to see anybody post 
a real-world example of what is being talked about, let alone one that 
will affect the typical everyday D programmer.  Having some examples 
would help put the problem in better perspective.

Stewart.