On Mon, 18 Oct 2010 10:49:25 -0400, Pelle <[email protected]> wrote:
On 10/18/2010 02:41 PM, Steven Schveighoffer wrote:
On Sun, 17 Oct 2010 02:57:02 -0400, Nick Sabalausky <[email protected]> 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.
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
