OT: std.logger was Re: std.experimental Timeline

[Dicebot via Digitalmars-d]

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 
wrote:
> 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 
designed.

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 :)