Lazy eval

[kris]

Frank Benoit wrote:
>>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.
> 
> 
> I use the { return ...; } very much. And I like it very much. And I
> fully agree that the return..; is annoying, because if often use it for
> a search criteria or something like that. The syntax { singlestatement }
> would be pretty cool. But leaving the braces completely out it terrible.
> And {} is really not too much to type.
> 
> Imagine the terrible bugs that will occur with that. I think one of the
> biggest advantages of D vs. C++ is the readability. That is so
> important. Really. Please don't destroy that.


I think the new sugar works really well where the code in question is 
*designed* around the notion of callbacks. The cues are already solidly 
in place at that point, so it may be less of an issue there? I'm 
thinking specifically of the logging examples, and some fairly advanced 
distributed processing paradigms.

However, in typical or 'mixed' D programming, the lack of cues in this 
latest sugar will surely become problematic. Walter suggests the author 
of the callee should use an appropriate name, such that overloading 
would (presumeably) not be an issue and the appropriate cues would be 
retained. One has to wonder if that is a good idea or not.

If it were possible to make the '{' '}' optional, for example, then 
another option would be for the coder to "make the call" as to how 
readable/explicit the code actually is. This is typical the case anyway, 
since any coder can write obfuscated code regardless of the language :)

The question is then "how much different is it to add or omit the 
'return' keyword?" ... personally, I think it makes a big difference; so 
does Walter, apparently. Thus, if we had a choice of writing these three 
options:


# int i;
# somefunk (++i);
#
# or
#
# somefunk ({++i});
#
# or
#
# somefunk (return {++i;});

I think the later should be dropped, and the former two supported :)