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.
