Lazy eval

[Sean Kelly]

Tom S wrote:
> 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 ;)

I'm not sure I'd want to do away with option 3 unless option 2 supported 
multiple statements and a void return in a way that made sense.


Sean