SLF4D - A proposal for a common logging interface for Dub projects

[Andrew]

On Friday, 24 February 2023 at 22:01:18 UTC, Tobias Pankrath 
wrote:
> Why not std.experimental.logger?

There are a few reasons that I had for this:
- There are already quite a few different logging implementations 
entrenched in the D ecosystem besides just std.logger (it's no 
longer experimental!), and I don't think everyone is going to 
push to std.logger just by virtue of it being in phobos.
- std.logger uses a mutable public shared logger instance. I 
personally don't like this approach, and I think it's cleaner if 
the logging configuration for an entire application is setup in 
one place, on application startup. That's why with SLF4D you 
(optionally) configure a logging provider as soon as you enter 
`main()`.
- The base `Logger` from std.logger is a class when, in my 
opinion, it doesn't need to be, if you want to provide extensible 
ways for handling the log messages that an application produces. 
It's easier for developers to learn to use a simple struct and 
its fixed set of methods, than to understand a type hierarchy.
- std.logger makes some approaches towards filtering, formatting, 
and distributing log messages, but it still seems very primitive 
to me, compared to mature logging frameworks in other languages 
(primarily python and java), and I would rather have the 
application logic completely separated from the logic controlling 
what happens to log messages after they're created.