Lazy eval

[Oskar Linde]

Walter Bright wrote:
> Frank Benoit wrote:
>> I think the lazy eval is a great feature, but in this form it has also
>> great drawbacks.
>>
>> The code isn't that much readable as it was before. You don't know what
>> will happen. Will that expression be evaluated or not? Or will it be
>> evaluated more than once?
> 
> It's true there is no clue from the user's side which it is. But there 
> also isn't a clue whether the arguments are in, out, or inout. 

A feature request that pops up now and then is to at least allow using 
the in/out/inout keywords at call site, just to help document the code.
That has analogs with the current discussion, but with delegates, we 
already have the option of explicitly using a {return...;} delegate 
where it makes sense.

Possibly, we might see coding guidelines one day, saying that one should 
write:

func(/*lazy*/ i++);

where the laziness has a semantic difference. I think it is a good idea 
to document your code as such, but the fraction of functions using lazy 
evaluation will probably be low, and the number of cases where the 
laziness of the function argument will have side-effects will be even lower.

>> func( "abc" ) calls func( char[] a )
>> func({ "abc" }) calls func( char[] delegate() dg )
>> func({ return "abc"; }) calls func( char[] delegate() dg )
>>
>> With that syntax one can immidiatly see "this is a delegate, if it is
>> called or not or more than once depends on func()" and the more typing
>> of {} is not too much.
> 
> I agree with you that replacing exp with { return exp; } is clear and 
> not much additional typing. But I've discovered over and over to my 
> surprise that the additional typing causes people to not realize that D 
> has that capability. The extra typing simply kills it.

Yes. I think the additional typing makes the feature seem more complex. 
In our search for solutions, we favor the most simple ones. By reducing 
the apparent complexity of a feature, it is much more likely to be used.

/Oskar