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

[Stewart Gordon]

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?

> In either case,
> by making opEquals const, it's impossible to have any state cached in the
> object or to have any state in the object which is lazily initialized.
<snip>

But that equally doesn't work with pure.

But why does the state need to be physically in the object, anyway?  The 
whole point of memoize is that it gets around the problem by storing the 
state outside the object.

Moreover, memoize can be made to work with pure by having something like 
@trusted that overrides purity instead of safety.  Or by going the whole 
hog and building it into the language.


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.

Stewart.