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
