Lazy eval

[Tom S]

kris wrote:
> 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 :)

You have a typo in the 3rd sample, it should read:
# somefunk ({return ++i;});

... which clearly shows that the 3rd option isn't the preferred one ;)

--
Tomasz Stachowiak