lazy redux

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Dec 7 10:21:50 PST 2009


Michal Minich wrote:
> Hello Andrei,
> 
>> Should we sack lazy? I'd like it to have a reasonable replacement.
>> Ideas are welcome!
>>
>> Andrei
>>
> 
> there are 3 sides from which to look at lazy function parameter.
> 
> 1. Usage - being able to send expressions to function is very important 
> for writing clear and nice looking code. I think just by requiring 
> enclosure in curly braces "fun({gun();})" would make this feature quite 
> less appealing and used. This syntactic feature is very pleasing - by 
> whichever feature at definition side it is achieved (macro/expression 
> type), it should stay here.

I think the same. But I seem to recall that at least one person on 
reddit thought it's a major loss of a guarantee.

> 2. Writing - On the function definition side, I don't see much 
> difference in *writing* "lazy int dg" or "int delegate () dg". The 
> functions that take lazy parameter are not written daily - their usage 
> is much more frequent (enforce, logging).

Nononono. There's a huge difference. If you have "lazy int x", then 
that's perceived as an int with some sort of storage class. Then a 
putative user would expect

auto y = x;

to define another int. In fact it's unclear whether y should be an int 
or a delegate. The presence of the delegate type clarifies what's going 
on. I could come up with several other examples that reveal "lazy int x" 
to be a complete crock.

> One problem I see currently with "lazy" that by specification it can be 
> evaluated zero or more times. For me, "lazy" means zero or one time 
> (compiler should handle this internally). This is not particularly 
> important, because it is probably not so hard for programmer to write 
> correct function - evaluation as many times as needed (which I think is 
> usually 0 or 1 anyway). Just, the name "lazy" does not seems correct to me.

I agree. That's why I say we yank it and at most allow function and 
delegate parameters to accept expressions. That approach has its own 
problems. Consider:

void fun(int delegate() dg) { ... }
int delegate() gun() { ... }

fun(gun());

In this case gun does get evaluated :o).


Andrei



More information about the Digitalmars-d mailing list