Possible way to achieve lazy loading with const objects

[Jacob Carlborg]

On 2011-09-24 06:11, Jonathan M Davis 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. 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

I like it.

-- 
/Jacob Carlborg