Why struct opEquals must be const?

Denis Koroskin 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  
> 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.

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 mailing list