On 10/11/2014 03:34 PM, Robert burner Schadek wrote:
>> - Why do loggers have to be classes?
> As answered multiply times before, to build log hierarchies.

You can easily create classes from structs, that's what I said 2 lines below.

> Add a Logger interface and a loggerObject to wrap structures when polymorphic loggers are needed.

On 10/26/2014 11:14 PM, Martin Nowak wrote:
>>>
>> As answered multiply times before, to build log hierarchies.
>
> You can easily create classes from structs, that's what I said 2 lines
> below.
And you could also log into a tuple of logger structs without polymorphism.

On 10/24/2014 02:16 PM, Robert burner Schadek wrote:
> On Friday, 24 October 2014 at 11:01:40 UTC, Martin Nowak wrote:
>> On Sunday, 12 October 2014 at 12:06:44 UTC, Robert burner Schadek wrote:
>>>> What's stopping an interface or class to implement a logging concept?
>>>
>>> Same as last time:
>>> Logger[], Logger without a LogLevel not real useful IMO, (new) no
>>> thread safety by default
>>
>> I don't understand your answer. Do you have a link to your last response.
>
> You can not tell if the Logger will log a message, because you can't
> know its LogLevel. It is not thread safe because the interface can't
> have an implementation. Therefore the default implementation is not
> thread safe.

Well then the concept is that a Logger has some method that returns the LogLevel (might be a runtime value). Where is the problem? We use this for empty in ranges for example.

On Sunday, 26 October 2014 at 22:12:20 UTC, Martin Nowak wrote:
> On 10/25/2014 06:43 PM, Dicebot wrote:
>> Because of that I am going to start voting despite some arguments being
>> still in process. I hope that won't cause any tension.
>
> The dependency on external version identifiers in phobos is still a complete bummer and there are still many implementation issues.
> One reason why this is taking so long is that there were many issues some of which still need to be addressed.

it is not really a dependency as the one template that uses the version identifier uses them optionally.

please name the issues that are not because of the gc.

On Sunday, 26 October 2014 at 22:27:55 UTC, Robert burner Schadek wrote:
>>
>> The dependency on external version identifiers in phobos is still a complete bummer
>
> it is not really a dependency as the one template that uses the version identifier uses them optionally.

And I forgot to add, no better solution presented itself in one year.

On 10/26/2014 11:27 PM, Robert burner Schadek wrote:
> it is not really a dependency as the one template that uses the version
> identifier uses them optionally.

It simply doesn't work, e.g. you could not statically disable logging in phobos without recompiling phobos.

cat > lib.d << CODE
version (StdLoggerDisableLogging)
    enum isLoggingActive = false;
else
    enum isLoggingActive = true;

void doSome()
{
    import std.stdio;
    writeln("isLoggingActive: ", isLoggingActive);
}
CODE

cat > main.d << CODE
import lib, std.stdio;

void main()
{
    writeln("isLoggingActive: ", isLoggingActive);
    doSome();
}
CODE

dmd -version=StdLoggerDisableLogging -lib lib.d
dmd main lib.a
./main

On 10/26/2014 11:29 PM, Robert burner Schadek wrote:
>
> And I forgot to add, no better solution presented itself in one year.

Well I showed one solution, but reduce it to its essence.
If you allow to define a Logger with a LogLevel know at compile time and you statically pass the LogLevel of your message to the logging function you can elide that call. For anything else you need a runtime check.

http://dpaste.dzfl.pl/2538c3b5d287

On 10/27/2014 12:45 AM, Martin Nowak wrote:
> but reduce it to its essence.

but let's reduce

On 10/27/2014 12:45 AM, Martin Nowak wrote:
> If you allow to define a Logger with a LogLevel know at compile time and
> you statically pass the LogLevel of your message to the logging function
> you can elide that call. For anything else you need a runtime check.

You are trying to globally define a LogLevel through the version identifier but that collides with D's separate compilation.
So you cannot enable logging in a library that was compiled with StdLoggerDisableLogging. And vice versa you cannot statically disable logging in a library compiled without StdLoggerDisableLogging.

Now if you use StdLoggerDisableLogging in your program the effect on the library will depend on whether or not you're calling a templated function or if the compiler inlined certain library function into your program.

On 10/11/2014 03:34 PM, Robert burner Schadek wrote:
>>
> As answered multiply times before, to build log hierarchies.

You don't need classes for hierarchies. You need them for runtime polymorphism. We're already building complex hierarchies with Ranges, same can be done for loggers, see http://dpaste.dzfl.pl/2538c3b5d287#line-140.