[Issue 24468] stdThreadLocalLog does not print `log` and `trace` logs

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=24468

Forest <forestix at nom.one> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |forestix at nom.one

--- Comment #3 from Forest <forestix at nom.one> ---
The experience I had today as a newcomer to Phobos logging:

- Read the std.logger docs.
- Create a StdForwardLogger for each of my modules.
  (I want to control each module's log level separately.)
- Discover that trace log messages are silently discarded.
- Set my logger's log level.
- Discover that trace log messages are still silently discarded.
- Read the std.logger docs again.
- Set globalLogLevel.
- Discover that trace log messages are still silently discarded.
- Read the std.logger docs again.
- Set sharedLog.logLevel.
- Discover that the compiler won't let me
  (none of the overloads of `logLevel` are callable using a `shared` mutable
object)
- Read the std.logger docs again.
- Notice how much time this basic task is taking, and swear in exasperation.
- Grovel through the dlang forum archive in search of help.
- Find the magic incantation here:
  https://forum.dlang.org/post/mveqddfktkykwvhombsl@forum.dlang.org
  (cast()sharedLog).logLevel = LogLevel.all;
- Try the magic incantation.
- Discover that the compiler won't let me use it in @safe code.

A default log level higher than `trace` is no surprise; that's reasonably
common in logging libraries. However, dealing with it in Phobos is surprisingly
painful.

In particular, the solution has at least these problems:

- It's nonintuitive.
- It's not clearly documented.
- It's unreasonably awkward for something as common as logging.
- It doesn't work at all in @safe code.

After finally getting to the bottom of it (and nearly giving up on D because
this is far from the first Phobos usability problem to bite me) I see that I
could work around it in my own programs by using @trusted code. However, I'm
writing a library, and I really don't want to require that its users resort to
library-specific functions or @trusted shenanigans to control such basic
functionality as logging.

It would be nice if this was either fixed by a revised std.logger design, or at
least hidden behind a clearly documented standard interface.

--