Hello Andrei,
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.
what he would think of Lisp then :-)
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.
You are right, I didn't noticed that. I always perceived "()" in "foo()"
as forcing of computation. Properties or real lazy evaluation could solved
this maybe, but ...
Yank it.
Although the possibility to specify if delegate accept expression or just
function pointer really should be retained. How about:
void fun (@expr int delegate () dg) {...}
instead of lazy. While normal delegate parameters will work as they are now.
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).
@expr above does not have this prob.
Andrei
I think @expr delegate is it.
Another possible ussage could be:
@expr int delegate () x = 1 + 1;
@expr auto y = 1 + 1; // y has type "int delegate ()"
