Lazy eval -- an example issue

[Walter Bright]

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. You could argue "what about the 
efficiency?"

1) Passing a delegate is exactly the same number of instructions as 
passing a char[], i.e., it is two values being passed.

2) Actually calling the dg() will, of course, cost more instructions 
than just referencing a []. This is mitigated by, presumably, logging 
being normally off, and being overshadowed by the rest of the actual 
logging cost.

3) It is possible that the delegate can be inlined, thus eliminating any 
extra overhead.