Why struct opEquals must be const?
2korden at gmail.com
Sun Oct 17 00:02:00 PDT 2010
On Sun, 17 Oct 2010 10: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
> lazy caching.
> If comparison isn't always needed and requires a potentially expensive
> computation that isn't likely needed otherwise (for example, a wrapper
> string that does case-insensitive comparisons, if it's used in a
> that does more assigning/slicing/etc than comparing), then it may make
> 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
> 'Course, if there is a technical reason for the restriction, then all
> is moot.
I don't think there any. None of the Object's methods are const (e.g.
opEquals, toHash etc), why would struct need to be const?
More information about the Digitalmars-d