So, I've been thinking about this const/lazy evaluation problem again.<div><br><div>I think most of the complaints about D's const is due to the use of lazy evaluation for optimisation. I started wondering if there was room for a 'lazy' keyword.</div>
<div>Perhaps if you declared some function as lazy, then the compiler would be expected to cache the return value, and also generate its own dirty flag, which it may manipulate in its own way. The compiler should have all the information it needs within the lazy function to know what external influences would cause a dirtying of the state. If they are sibling members as is often the case, it should be easy for them to be tagged to mark the dirt bit dirty whenever they are modified... if they are external non-const factors, then I would expect a warning (or error?).</div>
<div><br></div><div>Just a thought anyway. Curious to know if anything like this has ever been considered... It might address the majority of the problems with D's const.</div><div>Ie, I imagine a lazy function could also be marked const, and either, the compiler would have to just ignore the lazy cache and perform a full evaluation when called within a const context, OR it would be the responsibility of the compiler to implement the dirty logic in a 'safe' way (with respect to thread safety... lock free primitive usage? etc)</div>
<div><br></div><div>Am I insane?</div><div><br></div><div>- Manu</div></div>