std.experimental.logger formal review round 3

[Brad Roberts via Digitalmars-d]

On 10/27/14, 1:49 PM, Dicebot via Digitalmars-d wrote:
> On Monday, 27 October 2014 at 20:42:10 UTC, Martin Nowak wrote:
>> Say I want to add tracing/logging to
>> [`parseJson`](http://dlang.org/library/std/json/parseJSON.html) or
>> [`findRoot`](http://dlang.org/phobos/std_numeric.html#.findRoot)
>
> This is exactly what is wrong :) Using std.logger inside Phobos itself is a big no. Actually even
> finding yourself in position where you may want to do it indicates some Phobos design issue.

Why?  I agree that large parts of phobos have little need for logging, but I question the general 
statement.  What's so special about phobos that suggests that no part of it should ever log?  How is 
it different from many other third party libraries that might be similar in nature?

Consider the std.net.curl.  I find it entirely reasonable to consider that it would have logging 
added to it.  It could be argued that that part of phobos could/should be removed, but ignore that 
for now and pretend its a full re-implementation of an http client instead if that helps.

Consider the scheduler work that Sean is doing.  I'll bet he's got printf's in there at some 
strategic points for debugging right now.  Most of those I can easily see translating into trace 
level logging.

The same holds for any higher level tasks that have any sort of complexities and need a way for 
developers to witness how those subsystems are executing after the fact.

My key point, phobos isn't and shouldn't be considered special here.  If it shouldn't be doing 
logging, then why and why doesn't that same logic apply to almost every other library that 
developers are going to use?

I suspect there's some philosophical differences at play.

My 2 cents,
Brad