Lazy eval -- an example issue

[Walter Bright]

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).


> I do think it's unfortunate that Kris' 
> logging code will be unable to accept both string and delegate 
> parameters however.

True, but I don't think it's a serious deficiency. At worst, Kris can 
define two sets of them with different names, one set with values and 
the other with delegate parameters.

> 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.

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.

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. Heck, you can't even know what ++i does without looking 
at the type of i. It might be a class instance with a bizarre operator 
overload.