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