Example code in std.logger.core doesn't even work
WebFreak001
d.forum at webfreak.org
Thu Jul 20 12:07:27 UTC 2023
On Tuesday, 18 July 2023 at 03:45:36 UTC, IchorDev wrote:
> On Wednesday, 12 July 2023 at 10:29:50 UTC, WebFreak001 wrote:
>> not a big fan of the changes and the fact that this got made
>> std.logger instead of the previous API, but it works at least
>
> How would you say the old API was better? (I didn’t use it for
> myself because the stuff in std.experimental usually has an
> unreliable API)
oh I think the new API is worse here primarily just the shared
change that is needed in absolutely _every_ project that uses
`trace`, since otherwise `trace` isn't able to output anything
unless you set the logger. (globalLogLevel can only reduce the
logs, but you can't enable trace log this way)
Seeing that something this basic didn't work without the @trusted
hack, but still getting into std.logger in the same release (!)
that introduced these changes really doesn't seem to fit with how
phobos works. Usually modules need to be field tested to get into
phobos, which certainly has some upsides and downsides, but for
this module, basically it got rewritten and immediately placed
into standard phobos. It kind of feels that in large projects how
the log levels work might eventually be found to be broken in a
way that can't be fixed.
Additionally it looks like it's quite a runtime-heavy
implementation, I think we might have been able to do a better
implementation that can be better optimized into less runtime
overhead. Don't know how much we can optimize the current
std.logger implementation in the future, but the whole dynamic
structure with like thread local logger forwarding to global
sharedLogger, etc. make it seem to be less able to do it than
something like e.g. passing logger objects/templates around.
More information about the Digitalmars-d
mailing list