std.experimental.logger formal review round 3

[Martin Nowak via Digitalmars-d]

On Tuesday, 28 October 2014 at 10:05:47 UTC, Robert burner 
Schadek wrote:
> On Tuesday, 28 October 2014 at 09:39:24 UTC, Martin Nowak wrote:
>> On Tuesday, 28 October 2014 at 08:38:50 UTC, Robert burner
>> Schadek wrote:
>>> Actually, that is only true for LogLevel given to a log call 
>>> at runtime. calls to info, trace etc. are guarded with static 
>>> if.
>>> So you're not paying any runtime overhead when calling log 
>>> functions with LogLevel build in their name.
>>
>> If I cannot change the version identifiers that a library was
>> compiled with then the static if is always true. So you have to
>> perform the check at runtime. The only way around that is to 
>> make
>> each library function that performs logging a template, be it 
>> by
>> passing a Logger with CT LogLevel or by turning functions into
>> template functions so that the version identifiers leak into 
>> the
>> library.
>
> every log call is a template function or method already.
>
>> The latter is more fragile because the compiler might omit
>> instatiating a template or it might inline a function.
>
> omitting the instantiation sound like undefined reference.
> I don't see the problem with inlining. 1. there are no log 
> functions only log templates. 2. The version statement will 
> either leave empty template functions bodies, if(false) { ... } 
> template functions bodies, or template function bodies that 
> perform regular LogLevel checks on runtime LogLevel.
>
> We're running in circles here. Lets find a new solution that 
> allows us to
> * dmd -version=StdLoggerDisableLogLevel -- disable a LogLevel 
> at CT of user code
> * that does not require a static Logger LogLevel
> * does not leak version statements into phobos
> * does not call log template functions where the LogLevel of 
> the version statement is part of the name, or at least yields 
> empty bodies for these template functions callls

Yep, let's try that.

I think part of the misunderstanding is that I'm thinking of an 
app as user code plus a number of libraries all on top of phobos. 
Say I have an app using vibe.d and I want to enable logging in my 
app, but disable it in phobos.
Was it even a design goal that logging can be enabled on a per 
library level?