Lazy eval

nobody nobody at mailinator.com
Mon Aug 21 15:31:09 PDT 2006


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 :(

   cast( :-) )
     ( arghhh!!! Please ... cast() is only for exceptional circumstances :( );



More information about the Digitalmars-d mailing list