I'm in 100% disagreement. If you don't add the f suffix, users
will write:
info(<user provided string that could contain format>);
This is a crash if the user provided string happens to contains
"%s".
I wouldn't use such an API which makes format bugs hard to find.
It does the right thing... there is an overload: without
additional arguments, the first argument (not necessary a string)
is not a format string.
2. No support for 24/7 (server) applications
In my opinion, I really need logging for applications that
possibly run forever.
With the FileLogger, the file will grow forever.
That's why most other frameworks provide something like a
RollingFileLogger or some "logrotate-aware" FileLogger.
Do you realize rolling loggers are not there because they are
supposed to be in another layer as subclasses of Logger?
Contrary to the NullLogger, writing a rolling logger is a
non-trivial task.
By the way: Instead of what I really need, I get a NullLogger.
I have no clue, why I never ever missed such an oddity.
I asked for it. And I use it, because I write libraries that
log warnings but don't forcefully require the users to provide
a Logger if they don't want to.
And that way, I can still write "logger.warningf" without "if"
everywhere.
