std.experimental.logger formal review round 3

[Robert burner Schadek via Digitalmars-d]

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