Lazy eval -- an example issue

[kris]

Sean Kelly wrote:
> Walter Bright wrote:
> 
>> Sean Kelly wrote:
>>
>>> I'll admit that doing so makes a difference to me, as it allows for 
>>> tricks that aren't possible with explicit delegate signifiers.  But 
>>> I'm undecided as to whether this is a "good thing" or not--I plan to 
>>> give it some time before I decide.
>>
>>
>> Good - I don't think any of us are prescient enough to see all the 
>> ramifications of this. Nobody predicted where C++ templates wound up 
>> (the good and the bad).
> 
> 
> C++ templates are well-intentioned and really quite powerful, but 
> they're a horrible hack, even when used as originally intended.  The 
> need for "template" as a means to distinguish dependent type names is a 
> perfect example of something that should be completely unnecessary.
> 
>>> And I'd like to note that all the tricks I'm thinking of for the new 
>>> syntax tend to involve refactoring existing code (which is 
>>> potentially dangerous, given the issue with side-effects) rather than 
>>> writing new code.  With new code I don't see much benefit to omitting 
>>> all evidence that a parameter will be converted to a delegate, as 
>>> it's something the user must be aware of to write correct code.
> 
> 
> In light of my opening paragraph, I really shoudn't have said "all."
> 
>> I can't stress this enough - one must *already* be aware of the 
>> declaration to write correct code. Implicit conversions can cause 
>> trouble, as well as in, out, inout, const, and all the other storage 
>> classes discussed.
> 
> 
> True enough.  But I consider this a somewhat different class of 
> unpredictable behavior, if only because it isn't something present in 
> this way in any other C-like language (C# 3.0 will have lambda functions 
> similar to this with a leading => at the call point).
> 
>> Previous discussions here frequently revolved around the need to put 
>> information in the function declaration so people have some guarantees 
>> about what the function does - const is a prime example. Another is 
>> the suggestion to move the contracts from the implementation to the 
>> declaration.
>>
>> There is no way to know what:
>>
>>     somefunc(++i);
>>
>> does without looking at the declaration for somefunc() - even without 
>> lazy evaluation.
> 
> 
> But the possibilities are rather limited, either i will be mutated or it 
> will not.  I suppose what worries me isn't that I need to look at the 
> declaration to determine what will happen with implicit delegate 
> conversion, but that even looking at the declaration won't tell me what 
> may happen.
> 
> By the same token, I actually like C's method of pass-by-reference 
> because call-side code inspection reveals which parameters may be 
> modified.  I think this is why I like the suggestion to retain curly 
> braces and perhaps derive the return value automatically--it makes the 
> contract between caller and callee explicit.
> 
> But this is a new feature and I do want to spend more time with it 
> before making a final decision.  If nothing else, I agree that time and 
> experience will reduce the chance of mistakes demonstrated recently, as 
> this becomes "just another tool" we have available.
> 
> 
> Sean


Tom's suggestion is to introduce a different style of delegate for this 
lambda expression thingy. That would resolve the difficulties here 
(assuming delegates can be auto-converted to the lambda expr; per Tom's 
suggestion).

But for delegate itself, it sure would be nice to have:

# somefunk ({++i});

as a shorthand for

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