Lazy eval -- an example issue

[Sean Kelly]

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