Lazy eval

[Derek Parnell]

On Mon, 21 Aug 2006 15:16:34 -0700, kris wrote:

> Derek Parnell wrote:
>> On Mon, 21 Aug 2006 14:18:04 -0700, Walter Bright wrote:
>> 
>>>Frank Benoit wrote:
>>>
>>>>I think the lazy eval is a great feature, but in this form it has also
>>>>great drawbacks.
>>>>
>>>>The code isn't that much readable as it was before. You don't know what
>>>>will happen. Will that expression be evaluated or not? Or will it be
>>>>evaluated more than once?
>>>
>>>It's true there is no clue from the user's side which it is. But there 
>>>also isn't a clue whether the arguments are in, out, or inout. There 
>>>also is no syntactic clue what the function *does*. One must look at the 
>>>function interface and documentation to use it successfully anyway.
>>>
>>>It's going to take some caution to use this capability in a productive way.
>>>
>>>
>>>>There is no possibility to choose between
>>>>
>>>>func( char[] a ) vs. func( char[] delegate() dg )
>> 
>> Would it possible to use ...
>> 
>>    func ( cast(char[]) "abc" );
>> 
>> to force the compiler to chose 'func( char[] a)' instead of the delgated
>> version?
>> 
> 
> arghhh!!! Please ... cast() is only for exceptional circumstances :(

And this situation is not exceptional? Okay, than how about a keyword ...

  func ( forget_the_delegate_and_use_the_other_type_instead "abc" );

;-)


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
22/08/2006 10:43:28 AM