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.
