lazy redux

[Michal Minich]

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 ()"