Possible way to achieve lazy loading with const objects

[Jonathan M Davis]

On Thursday, September 29, 2011 10:50 Steven Schveighoffer wrote:
> On Thu, 29 Sep 2011 13:48:02 -0400, Peter Alexander
> > The comparison may involve comparing a sub-object that is lazily
> > created. It could also involve computing a cached perfect hash for
> > faster comparison, requiring memoization.
> 
> Neither of these are required for opEquals to work. They are
> optimizations.

True, but by making opEquals const and only const, you're disallowing such 
optimzations. It becomes impossible for someone to do any kind of lazy loading 
at all. So, in principle, I definitely think that opEquals should be const, 
and practically-speaking it _needs_ to be const for const to work properly, 
but if we make it _only_ const, then we're disallowing some performance-
related stuff that some people care a lot about. Also, if we force opEquals to 
be const, then those classes that just _can't_ be const and work properly 
(e.g. those that _require_ logical const to even work - like if they have a 
mutex) won't be usable at all. So, making it both seems to be the only real 
option.

Though come to think of it, since you _still_ can't have lazy loading when a 
const opEquals even _exists_, you're either still going to have to forgoe lazy 
loading, make the const opEquals throw, or get nasty bugs when the non-
overridden base class version of opEquals gets thrown. So, this could be even 
worse than we were thinking...

I'm not quite sure what the correct solution is then. By having both, we allow 
for both paradigms but make the use of const opEquals potentially buggy in the 
cases where someone insists on doing lazy loading. But if we insist on only 
having the const opEquals, then some folks are going to get an unavoidable 
performance hit in their programs. If caching is the only issue, then it's a 
non-issue, because the const versions just become less efficient in the cases 
where the value is dirty, but if the state of the function actually needs to 
be changed for opEquals to work (e.g. lazy loading or internal mutexes), then 
we're going to have cases where the const opEquals can't possibly work 
correctly.

This is ugly.

- Jonathan M Davis