Lazy eval

[kris]

Walter Bright wrote:
> Frank Benoit wrote:
> 
>> For example i have a container with a add( element ) method. Now this
>> method is implemented with lazy-eval, if the container is already full,
>> the argument is not evaluated.
>> Or the get( index ) method does not eval the arg if the container is
>> empty. And every time I have not only to remember the method name and
>> arguments, now I have to know details of the implementation.
>> Great, that was the silly thing they wanted to take away from me with
>> this OOP ;)
>>
>> Solution: Force the user the make {} around a delegate argument.
>>
>> Now I get a compiler error when writing container.get(i++); Then I know,
>> this is a delegate, take care with the increment, writing
>> container.get({i}); i++;
> 
> 
> While I understand your concern, I don't think the examples illustrate 
> it. If a get() is done for an element that doesn't exist, the usual way 
> to deal with it is throw an exception, and have some complex scheme to 
> try and undo the side effects from evaluating the argument. With lazy 
> evaluation, no need to undo the side effects, as only if the get() is 
> guaranteed to succeed will the argument be evaluated.
> 
> The problem with requiring the { } around the argument is that 
> programmers just don't like it. I don't think I can make them like it.

Can you at least make it optional? Or, can you come up with an operator 
or something that is low-impact? Making this unambiguous instead would 
surely be a win-win?