Possible way to achieve lazy loading with const objects

[Jonathan M Davis]

On Thursday, September 29, 2011 14:55:37 Steven Schveighoffer wrote:
> I think the caching/lazy loading *specifically for opEquals* has been
> blown way out of proportion.  I don't think I've ever written one which
> requires caching to be efficient.

Caching is non-issue. It's just less efficient if you can't update the cache on 
an opEquals call. Semantically, you're fine. The problem is lazy loading. If 
you don't actually set the variable until its getter  property is called, and 
the getter property has never been called prior to opEquals being called, then 
opEquals _can't_ properly do its calculation, because the value hasn't been 
loaded yet. Now, assuming that the value is lazily loaded in a pure manner, 
then you could have a const overload of the property which just does the 
calculation without actually changing the state of the object, but if the 
value can't be loaded purely, then that doesn't work.

Personally, I don't care much about lazy loading. I _never_ use it. However, 
several folks have been saying that it's important to them and their D 
programs, and as far as I can see, forcing opEquals to be const makes that 
impossible for them. But maybe the solution is that they're just going to have 
to throw from opEquals if not everything has been loaded yet and either make 
sure that they load all values before calling it or use something other than 
== for equality comparison (though honestly, it reflects really poorly on D if 
people are forced to reimplement their own equals function because of const).

I don't know what the best solution is, but it's clear that this is a case 
where const is causing problems. opEquals _must_ be const for const to work 
correctly, but making it const eliminates - or at least seriously hampers - 
some peformance-critical solutions.

- Jonathan M Davis