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
