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