Why are opEquals/opCmp arguments not in or const for Objects?

Jonathan M Davis jmdavisProg at gmx.com
Mon Mar 18 17:46:02 PDT 2013


On Tuesday, March 19, 2013 00:26:40 Stewart Gordon wrote:
> On 18/03/2013 23:06, Jonathan M Davis wrote:
> > On Monday, March 18, 2013 22:11:49 Stewart Gordon wrote:
> <snip>
> 
> >> Look up std.functional.memoize.
> > 
> > It doesn't work with pure as it forces you to put state outside of the
> > object, and it's only applicable to caching, not lazy initialization.
> 
> 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.

> In any case, if you find yourself having to prevent const objects from
> being compared for equality or whatever, then you need to rethink your
> strategy. Or at the very least, define a const version as well. By
> having the const version in Object, it doesn't prevent someone from
> additionally defining a non-const version that speeds up subsequent
> calculations by storing something extra in the object. This could
> possibly be used by the const version as well.

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.

Even if it's generally best practice for opEquals to be const, it's needless 
restrictive to require it. D is a systems language, and needs to be flexible 
and pragmatic. We do _not_ want to force const on people. D's const is far too 
restrictive to require it.

It was already agreed upon by Walter and Andrei that we would get rid of 
opEquals, opCmp, toHash, and toString on Object. It's just a question of doing 
what needs to be done to make that possible and providing an appropriate 
transition path.

- Jonathan M Davis


More information about the Digitalmars-d mailing list