Why struct opEquals must be const?

Rainer Deyke rainerd at eldwood.com
Mon Oct 18 14:31:31 PDT 2010


On 10/18/2010 13:51, Steven Schveighoffer wrote:
> On Mon, 18 Oct 2010 15:43:29 -0400, Rainer Deyke <rainerd at eldwood.com>
> wrote:
>> On 10/18/2010 09:07, Steven Schveighoffer wrote:
>>> What case were you thinking of for requiring mutablity for equality
>>> testing?
>>
>> What about caching?

> The object's state is still changing.

Yes, that's my point.  D doesn't have "logical const" like C++, so not
all logically const operations can be declared const.  opEquals is
always logically const, but it cannot always be physically const.

> If you think it's worth doing, you can always cast.  Despite the label
> of 'undefined behavior', I believe the compiler will behave fine if you
> do that (it can't really optimize out const calls).

Not safe.  The set of const objects includes immutable objects, and
immutable objects can be accessed from multiple threads at the same
time, but caching is not (by default) thread-safe.


-- 
Rainer Deyke - rainerd at eldwood.com


More information about the Digitalmars-d mailing list