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