Lazy eval -- an example issue

[Oskar Linde]

kris wrote:
> Walter Bright wrote:
>> kris wrote:
>>
>>> So, we have some existing code for logging. Very efficient, and 
>>> highly flexible. It follows the design patterns popularized by Log4J, 
>>> with Appenders, Layouts, etc
>>>
>>> The D version of a logger has five 'levels' of logging:
>>>
>>> log.trace (char[])
>>> log.info (char[])
>>> log.warn (char[])
>>> log.error (char[])
>>> log.fatal (char[])
>>>
>>> and the intent (with dmd.164) was to add these flavours, specifically 
>>> to address the point Walter makes about unnecessary message 
>>> construction:
>>>
>>> log.trace (char[] delegate() dg)
>>> log.info (char[] delegate() dg)
>>> log.warn (char[] delegate() dg)
>>> log.error (char[] delegate() dg)
>>> log.fatal (char[] delegate() dg)
>>>
>>> The support code was installed fairly recently, and the above 
>>> delegate-wrappers were on the todo list.
>>>
>>> However, dmd.165 will presumeably not compile this code?
>>
>>
>> Correct.
>>
>>> Won't there be an overload ambiguity?
>>
>>
>> Yes.
>>
>>> If so, it illustrates a serious shortcoming in the new syntax
>>
>>
>> Just get rid of the (char[]) versions.
> 
> 
> Can't do that; the char[] version have to stay.

This may not be a very clean solution, but you could make them 
templates, using ifti. (If that only worked for member functions...)

trace(T)(T str) {...}

Then

trace("string");

will not be called lazily, while

trace({return "string";});

will.

/Oskar