Possible way to achieve lazy loading with const objects

[Jonathan M Davis]

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. I really don't know how we could possibly do 
caching with const, but I _do_ have an idea of how we could implement lazy 
loading. Here's what it looks like syntactically:

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).

7. An opCast is added to S for shared S and immutable S which calls __varProp 
- or if such on opCast already exists, the call to __varProp is added at the 
end of it.


The result of all of this is that the value of var is constant, but it isn't 
calculated until it's asked for. It doesn't break const at all, since the 
compiler can guarantee that altering the value of __varLoaded and __var is 
safe. And since the value is eagerly loaded in the case of immutable and 
shared, immutable  and shared don't cause any problems.

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?

Again, I'm not necessarily suggesting that we implement this right now, but it 
at least _seems_ like a viable solution for introducing lazy loading in const 
objects, and I'd like to know whether there's a good possibility that it will 
actually work to implement something like this in the compiler. If it _is_ 
feasible, and we want to actually do it, since it's backwards compatible (as 
far as I can tell anyway), we can implement it at some point in the future 
when D has stabilized more, but I thought that the idea was at least worth 
dicsussing.

I'm not at all convinced that the added complexity to the language and to the 
compiler is worth the gain, but there are a number of programmers who want 
some sort of lazy-loading ability for member variables in const objects, and 
this seems to provide that.

- Jonathan M Davis