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