std.experimental.logger formal review round 3

[Robert burner Schadek via Digitalmars-d]

On Monday, 27 October 2014 at 20:49:35 UTC, Dicebot 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.

Yes and No. His Logger can came from the user aka. outside of 
phobos. That might just be valid. But the problem with the design 
is that he needs to accept every possible Logger. And that either 
means template of abstract class Logger.

The problem with a template is:

``` library code that is given in binary form
auto fun(Logger l) {
    return parseJson(getData(), l);
}
```

their is no choice but to pass a class. Meaning you have to wrap 
the struct Logger with a class proxy. And this will properly 
develop into a common theme.

Allowing struct has one design problem IMO:
Either we force to callee to accept Logger as template or
we force the caller to wrap his Logger struct with Logger proxy 
classes.
This is because an abstract class is the lowest common 
denominator in this case.

Anyway, I'm pretty sure that Martin and I will never see eye to 
eye in this discussion. IMO disabling a single Logger through its 
LogLevel at compile (plus all the extra litter and possible 
needed wrapping) is no better than creating NullLogger. He thinks 
the opposite.

The problem for me now is, if I add a struct UFCS overload Martin 
will be happy but somebody else will stream WAT "The struct stuff 
must go"

So please everybody reading this, please give a comment about 
this.