Lazy eval

Chris Nicholson-Sauls ibisbasenji at gmail.com
Fri Aug 25 16:48:20 PDT 2006


Stewart Gordon wrote:
> Chris Nicholson-Sauls wrote:
> 
>> Stewart Gordon wrote:
>>
>>> Frank Benoit wrote:
> 
> <snip>
> 
>>>> This is the first example, showing a ambiguity
>>>> func( char[] a ) vs. func( char[] delegate() dg )
>>>
>>>
>>> If one overload matches exactly, it goes without saying that that's 
>>> the one that's called.  As such, the programmer would do
>>>
>>>     func("qwert");
>>>
>>> to call the first, and
>>>
>>>     func({ return "qwert"; });
>>>
>>> to call the second.  Just like in any other case.
>>
>>
>> That's what I would have thought as well, but its already been said 
>> that these cases are considered ambiguous...  For example, the 
>> following code:
> 
> 
> Said by whom, where exactly?  Moreover:
> 
> http://www.digitalmars.com/d/function.html
> 
> "In D, function overloading is simple. It matches exactly, it matches 
> with implicit conversions, or it does not match. If there is more than 
> one match, it is an error."
> 
> The irony is that this seems to be a case of what this sentence says, 
> rather than what it was actually supposed to mean.
> 
> <snip>
> 

I know I've read it, don't recall exactly by whom or suchlike.  However, it speaks for 
itself, try it with DMD 0.165 and behold the error.  Mind you I'm in agreement that it 
shouldn't be that way: thus I feel the lazy evaluation feature, while nifty and full of 
Trendy Cooltasticism (TM), is essentially b0rked in DMD165.  I do look forward to the next 
version and the 'lazy' parameter class.

-- Chris Nicholson-Sauls



More information about the Digitalmars-d mailing list