On Sat, 24 Sep 2011 00:11:52 -0400, Jonathan M Davis <jmdavisp...@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
