lazy redux

Michal Minich michal.minich at gmail.com
Mon Dec 7 04:14:01 PST 2009


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.

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). 

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.

3. Contract - It was mentioned that programmer may expect "foo" to be always 
called in "bar (foo())". In case bar takes lazy argument, it may not be called. 


We need to have function which takes expression as parameter, while being 
able to separately express that function takes delegate. This should minimize 
cases of possible mismatched parameters. If we would replace "lazy" with 
explicit delegate parameter specification in function declaration, we would 
lost this possibility, and I think there would be more bugs cased by mismatched 
parameters.

So I think we should leave "lazy" in, until we have macros. But introduction 
"{ epx }" as delegate/function literal for functions with no arguments, which 
implicitly returns result of the expression, seems to me as a good idea.





More information about the Digitalmars-d mailing list