Lazy eval

[kris]

Sean Kelly wrote:
> 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


True; and some have pointed out potential problems with #2.

It's worth noting that C# uses the '=>' operator for the equivalent 
sugar: IIRC the equivalent example in C# would be

# somefunk (i => ++i);

so, perhaps, just perhaps, it's worth introducing an operator (*gasp*) 
specifically to make this completely unambiguous? For example:

# somefunk (@++i);

where '@' (or whatever) would be a low-priority operator ?