OT: std.logger was Re: std.experimental Timeline
Dicebot via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jan 5 08:34:27 PST 2016
Sorry for late reponse, I don't read NG that often now.
On Monday, 4 January 2016 at 17:06:16 UTC, Robert burner Schadek
> I actually have a patch in the pipeline for this,. That patch
> require to change the protection for beginLogMsg, logMsgPart,
> finishLogMsg from protected to public and bye bye cast.
> logMsgPart already takes a const(char). I actually thought
> the protection was public to begin with.
Very good, this will get rid of one of API problems I was going
to mention :)
> Yes the cast is ugly, but then I'm writing dynamic content into
> stack arrays.
It is not just ugly, it is undefined behavior by D specification.
You are casting to immutable data that will inevitably going to
change. Most likely it will work on all existing compilers but
such code won't pass any decent code review.
With protection changes it becomes possible to avoid LogEntry
though so this becomes sort of fixed. However ..
> BTW, the default implementation is a direct result of the "by
> default multi-threading safe" requirement brought up multiple
> times during reviews.
.. this remains a concern. I know that with some tweaks and lot
of custom overriding I can build logging system that works with
reusable buffers. However, it would be incompatible with any 3d
party logger which is defined in terms of `LogEntry` and that
kills the main benefit of having standard API in the first place.
I'd like (if it is even possible) to have a fast thread-safe
no-allocation logger with thread-local proxies as a default one
available because it is both very common demand from a logging
system and will influence how derived 3d-party loggers will be
But that can be a more problematic task because `const(char)`
is not implicitly shared and we don't have any good guidelines
for sharing mutable data in Phobos :) Right now I have no idea
what should be done - it is simply a problem that is likely to
result in at least some API changes and a good example why just
being in std.experimental for a long period doesn't safeguard
against finding unexpected API issues (I have only realized the
issue several weeks ago, despite being the review manager of
original proposal and reading it in great details).
> Anyway, if people have issues with std.(experimental.)logger,
> please write to the forum, bugzilla, github, or directly to me.
As I have mentioned in the e-mail, I will do so as soon as I will
have any half-decent proposal and will be able to help :)
More information about the Digitalmars-d