Lazy eval

[Lutger]

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

As for ambiguity between overloads, doesn't it make more sense to change 
  the overloading rules so that 'func( char[] a)' takes precedence, if 
this can be done?
I'd think that it would make sense as it is similar to how implicit 
conversions for integral types work. The {} syntax would then 'force' 
the second form to be taken, but this is no cast.
Then again, I could be very wrong.