Possible way to achieve lazy loading with const objects

[Peter Alexander]

On 26/09/11 6:57 PM, Jonathan M Davis wrote:
> On Monday, September 26, 2011 10:26 Steven Schveighoffer wrote:
>> I still don't think this proposal (even one that always lazily
>> initializes) gives enough benefit to be included. Why would you want a
>> constant lazily-initialized value in a non-immutable struct? If this were
>> to mean anything, there would have to be a way to clear the 'set' flag in
>> a mutable struct.
>
> People have been complaining about the lack of logical const. The two use
> cases that they seem to have been looking for are the ability cache the
> results of member functions and to lazily load member variables. They want to
> be able to do those things with const and can't (in the case of Peter
> Alexander, he seems to have come to the conclusion that it's bad enough that
> he doesn't use const for anything not related to threaings, though I do find
> that stance a bit odd, since it's _immutable_ that's needed for threading, not
> const). I was merely trying to present a solution to lazy loading that worked
> with const. It would therefore partially solve the issues that people have
> been complaining about.

Yes, immutable is needed for concurrency, but const has the same 
restrictions: if something is const then you can't do lazy loading, 
internal caching, or anything else that you might want to do with 
logical const.

Given that:

(a) I may want/need to use logical const,
(b) I want my code to be const-correct, and
(c) const is incredibly viral in D

That gives me no choice but to not use const in any situation where I'm 
not 100% certain that logical const won't be needed in the future. 
Otherwise I may end up trapping myself, forced to resort to undefined 
behaviour, or restructure the use of const in a large amount of my code. 
I've had to do this even in large C++ code bases more than once, and 
it's not fun. With D it would be a lot worse, and that's something I'd 
like to avoid.


> Personally, I don't think that the feature merits the extra complexity that it
> incurs. I was just proposing a possible solution. And it seems that some folks
> (Peter in particular) don't think that it goes far enough to be of any real
> value anyway (he wants full-on caching, not lazy loading). Personally, I don't
> even remember the last time that I used lazy loading or caching in a type, so
> the feature was never intended for me anyway, and finding out why folks would
> find it useful would really require their input. But there _are_ people who
> have wanted lazy loading to work with const objects; they just also want
> generally caching to work as well, which isn't at all feasible as far as I can
> tell, whereas lazy loading seems like it could be.

You're right, it isn't feasible. Enforcing logical const is intractable.