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