Possible way to achieve lazy loading with const objects

[Steven Schveighoffer]

On Sat, 24 Sep 2011 00:11:52 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> Okay. I'm not saying that we should necessarily implement this. I'm just
> looking to air out an idea here and see if there are any technical  
> reasons why
> it can't be done or is unreasonable.
>
> Some programmers have expressed annoyance and/or disappointment that  
> there is
> no logical const of any kind in D. They generally seem to be trying to  
> do one
> of two things - caching return values in member functions or lazily  
> loading
> the values of member variables.

The major reason for having logical const is to a) store state on the  
object that is not considered part of the object, or b) store references  
to objects that are not part of the object state.

For example, storing a reference to a mutex in an object, or a reference  
to an owner object.  It's the difference between a "has a" relationship  
and a "points to" relationship.

Your lazy loading idea does not help at all for these.

> struct S
> {
>     lazy T var = func();
> }
>
> The lazy indicates that var is going to be lazily loaded, and func  
> returns the
> value that var will be initialized with. However, instead of being a  
> normal
> variable of type T, this is what happens to var:
>
> 1. Instead of a member variable of type T, S gets a bool (e.g.  
> __varLoaded)
> and a variable of type T (e.g. __var).
>
> 2. __varLoaded is default-initialized to false, and __var is void (so,
> garbage).
>
> 3. Every reference to var is replaced with a call to a getter property
> function (e.g. __varProp). There is no setter property.
>
> 4. __varProp looks something like this:
>
> T __varProp()
> {
>     if(!__varLoaded)
>     {
>         __var = func();
>         __varLoaded = true;
>     }
>
>     return __var;
> }
>
> 5.  __varProp may or may not be inlined (but it would be nice if it  
> would be).
>
> 6.  If the S being constructed is shared or immutable and __varProp is  
> not
> called in the constructor, then __varProp is called immediately after the
> constructor (or at the end of the constructor if that works better for  
> the
> compiler).

Why?  What if the calculation is very expensive, and you never access var?

Besides, we can already pro-actively initialize data in an immutable  
constructor, what is the benefit here?

> So, the question is: Does this work? And if not, why? And if it _does_  
> work,
> is it a good idea? And if not, why?

It doesn't solve the problem.

-Steve