Lazy evaluation

[Jonathan M Davis]

On Wednesday, November 23, 2011 00:23:16 Timon Gehr wrote:
> On 11/22/2011 11:00 PM, Manu wrote:
> > So, I've been thinking about this const/lazy evaluation problem again.
> > 
> > I think most of the complaints about D's const is due to the use of lazy
> > evaluation for optimisation. I started wondering if there was room for a
> > 'lazy' keyword.
> > Perhaps if you declared some function as lazy, then the compiler would
> > be expected to cache the return value, and also generate its own dirty
> > flag, which it may manipulate in its own way. The compiler should have
> > all the information it needs within the lazy function to know what
> > external influences would cause a dirtying of the state. If they are
> > sibling members as is often the case, it should be easy for them to be
> > tagged to mark the dirt bit dirty whenever they are modified... if they
> > are external non-const factors, then I would expect a warning (or
> > error?).
> > 
> > Just a thought anyway. Curious to know if anything like this has ever
> > been considered... It might address the majority of the problems with
> > D's const.
> > Ie, I imagine a lazy function could also be marked const, and either,
> > the compiler would have to just ignore the lazy cache and perform a full
> > evaluation when called within a const context, OR it would be the
> > responsibility of the compiler to implement the dirty logic in a 'safe'
> > way (with respect to thread safety... lock free primitive usage? etc)
> > 
> > Am I insane?
> > 
> > - Manu
> 
> I'd say variables would have to be declared as lazy, not functions. Then
> you could set the dirty flag manually on mutable instances. Const
> instances that refer to mutable data would benefit from lazy evaluation
> while immutable instances would have to compute the lazy members during
> their construction. This usage clashes with the current call by name
> semantics of the lazy parameter storage class though.

This basic idea was discussed a couple of months back, and it was determined 
that it was overly complicated for very little gain.

- Jonathan M Davis