Feedback/Suggestions for std.log

[Gary]

1. Background

Hi all, first time posting.
This message is in response to Andrei's first call for feedback on the 
proposed std.log interface.

I'm piping up on the log topic because of recent experience using a 
logging library ("log4cxx") on a project at work.

I'll attempt to identify our teams' requirements of the logging library, 
and transition into suggestions for D's "std.log", and why D is a 
powerful language in which to implement a versatile log.

I also, in these suggestions, dare make the assumption that the goals of 
std.log include accommodating audiences and users similar to my humble 
team members and myself. If this assumption is incorrect or the scope of 
the suggestions is too large for std.log, by all means pull me back down 
to Earth.

2. Requirements (for our team's logging functionality), and features 
which accommodate them

- Must be scalable with respect to project size
-- Feature: Allow custom log destinations specified at compile or 
run-time, and log level options specified at logger instantiation 
(compile time) or at run-time.
-- Feature: Allow loggers to exist in a hierarchy, in which properties 
of parent loggers are shared with children.
--- Our team of 18 developers must make judgments about what to log and 
when. Depending on the diagnostic activity, it is necessary to 
enable/disable logging in specific domains of the application. The 
ability to shut off logging in certain parts of the program at run time 
is paramount to success in debugging certain issues, from our experiences.
--- The hierarchy helps in being able to shut off a large branch of 
loggers by specifying the level for just one ancestor. Also the 
hierarchy format (at least in our case) maps well to the organization of 
objects across our domains.

- Must be performant

- Log calls and interaction must be concise, readable code
-- Feature: Minimal setup code, minimal code at log call site
--- Our team has felt the pain of supporting and troubleshooting our 
products at customer sites, with irate customers present. Each 
illuminative log statement is worth it's weight in gold, but we're also 
cognizant of maintainability of software, and code with verbose comments 
becomes difficult to read.
--- I opine: the current interface for std.log currently achieves good 
readability! Awesome!
-- Feature: Allow code/logic to be run inside the conditional block of a 
log call.
--- An example of our need for this is the need to print specific data 
from each member of a list of objects. Rather than incur log call 
overhead on each iteration over a list (much less not being able to 
compile away that logic), the most efficient solution seems to be 
allowing logic in the log conditional block.
--- Of course, somebody somewhere will misuse this and put "business" 
logic in there, and compile out a small but necessary tidbit which made 
their program function.
--- From my very rough understanding after reading the Lazy Evaluation 
article on "d-programming-language.org", this can be possible with the 
current std.log interface:
                 Sample pseudo-code:
                 logInfo({
                 auto msg = "Video modes found: ";
                 foreach( mode, videoModes )
                 {
                 msg ~= to!string( mode.width ) ~ "x" ~ to!string( 
mode.height ) ~ ";";
                 }
                 return msg
                 });
--- log4cxx simply allows a query to the logger at run-time to find out 
the current log level.

I can provide success stories (well, success in finding and debugging 
issues) from having a few of these features in our logging library, but 
that could be boring so I'll hold back (available on request).

3. Suggestions
Well, the suggestions for std.log are basically the features described 
above :-) . It'd be an injustice to express a desire to recreate 
log4cxx/log4j in D, but certain features which log4cxx provides greatly 
enhance development on large teams.

I haven't thought through it, but I get the feeling D might accommodate 
creating the logger hierarchy at compile time, or rather avoid string 
(logger name) computations at run-time (log4cxx does all the string 
manipulation at run-time).

I hopefully have made a case for including these features. I believe 
they'd be helpful to larger teams and teams supporting somewhat complex 
commercial products.

I'm aware that it's very easy to ask for things when I'm not the one 
working to help provide them. Since I'd like to see this and other 
growth in the D language, I'll offer my help however I can.

Thanks,
Gary