On Thursday, 31 July 2014 at 15:41:40 UTC, Andrei Alexandrescu wrote:
> Then you have the globals write and writef which will compete with those in std.stdio. -- Andrei

Aren't they from different overload sets?

On 8/1/14, 4:00 AM, Kagamin wrote:
> On Thursday, 31 July 2014 at 15:41:40 UTC, Andrei Alexandrescu wrote:
>> Then you have the globals write and writef which will compete with
>> those in std.stdio. -- Andrei
>
> Aren't they from different overload sets?

Doesn't seem to me. They all accept e.g. one string. -- Andrei

On Friday, 1 August 2014 at 15:05:55 UTC, Andrei Alexandrescu wrote:
> On 8/1/14, 4:00 AM, Kagamin wrote:
>> On Thursday, 31 July 2014 at 15:41:40 UTC, Andrei Alexandrescu wrote:
>>> Then you have the globals write and writef which will compete with
>>> those in std.stdio. -- Andrei
>>
>> Aren't they from different overload sets?
>
> Doesn't seem to me. They all accept e.g. one string. -- Andrei

So what is the problem? We have module system to resolve that, do we?

On 08/01/2014 05:56 AM, Martin Nowak wrote:
> On 07/30/2014 01:09 AM, Robert burner Schadek wrote:
>>
>> I'm not sure how you except log(LogLevel.xxxx, "Hello world") to be
>> disabled at compile time if LogLevel.xxxx is a runtime value? Or do I
>> misunderstood you?
>>
>> you can choose to disable name based logging like trace("Hello trace")
>> at CT with the current release
>
> Here is a proof of concept to achieve this.
> http://dpaste.dzfl.pl/95fb6a4e086d
> It works by creating a different type for each loglevel.

Just checked tested this.

    static struct TestLogger
    {
        enum minLogLevel = LogLevel.error;
        void write(in LogEntry e) { _entries ~= e; }

        const(LogEntry)[] _entries;
    }

    void main()
    {
        TestLogger logger;
        logger.log(LogLevel.debug_, "foobar");
    }


The call logger.log(LogLevel.debug_) can be completely removed by the compiler. The delegates for the lazy parameters are still generated though.
Either fixing [`--gc-sections`](https://issues.dlang.org/show_bug.cgi?id=879) or adding [LTO](https://github.com/ldc-developers/ldc/issues/693) would help.
Also dmd (but not LDC) has a [bug](https://issues.dlang.org/show_bug.cgi?id=8615) where it still adds a few instructions to pass the delegate (even though the function is never called).

So I think it's an appropriate solution to the problem.
http://dpaste.dzfl.pl/95fb6a4e086d

On 8/1/14, 8:07 AM, Dicebot wrote:
> On Friday, 1 August 2014 at 15:05:55 UTC, Andrei Alexandrescu wrote:
>> On 8/1/14, 4:00 AM, Kagamin wrote:
>>> On Thursday, 31 July 2014 at 15:41:40 UTC, Andrei Alexandrescu wrote:
>>>> Then you have the globals write and writef which will compete with
>>>> those in std.stdio. -- Andrei
>>>
>>> Aren't they from different overload sets?
>>
>> Doesn't seem to me. They all accept e.g. one string. -- Andrei
>
> So what is the problem? We have module system to resolve that, do we?

Yah but there's this inconvenience when people import two stdlib modules and then they need to qualify calls. I agree it's more of a matter of perception/user education. -- Andrei

On 08/01/2014 05:07 PM, Dicebot wrote:
> On Friday, 1 August 2014 at 15:05:55 UTC, Andrei Alexandrescu wrote:
>> On 8/1/14, 4:00 AM, Kagamin wrote:
>>> On Thursday, 31 July 2014 at 15:41:40 UTC, Andrei Alexandrescu wrote:
>>>> Then you have the globals write and writef which will compete with
>>>> those in std.stdio. -- Andrei
>>>
>>> Aren't they from different overload sets?
>>
>> Doesn't seem to me. They all accept e.g. one string. -- Andrei
>
> So what is the problem? We have module system to resolve that, do we?

Exactly, that's the problem. They collide, so when import both the hijack protection will error.

import std.stdio, std.log;

write("foobar"); // matches both std.stdio.write and std.log.write

It'd also make it more difficult to tell what `write("foobar")` does,
which is unacceptable for such a fundamental operation.

On 08/01/2014 05:31 PM, Martin Nowak wrote:
> Exactly, that's the problem. They collide, so when import both the
> hijack protection will error.
>
> import std.stdio, std.log;
>
> write("foobar"); // matches both std.stdio.write and std.log.write
>
> It'd also make it more difficult to tell what `write("foobar")` does,
> which is unacceptable for such a fundamental operation.

We already have a similar issue with std.stdio.write and std.file.write that is fairly annoying.

On 08/01/2014 04:31 AM, Andrei Alexandrescu wrote:
> On 7/31/14, 7:19 PM, Martin Nowak wrote:
>> You cannot use version identifiers to selectively disable functionality
>> or people would have to compile their own phobos library for every set
>> of version combinations.
>
> Wait, doesn't code work with the version chosen by the user? -- Andrei
>

Well phobos as a library is precompiled, so the versions used to compile phobos will be relevant, not the ones in client code.

For templated functions version identifier will "leak" from client code into the library, because technically they are instantiated by the client code.

Also the version identifiers of client code determine which declarations you see.

Relying on this would be a constant source of bugs.

I did proof-of-concept yesterday using type tags and template constraints to statically disable certain log levels.
It also has some drawbacks because LogLevel is no longer a plain enum, but it's more appropriate than version identifiers.
http://forum.dlang.org/post/lrf362$tkn$1@digitalmars.com

On Friday, 1 August 2014 at 15:31:39 UTC, Martin Nowak wrote:
> Exactly, that's the problem. They collide, so when import both the hijack protection will error.
>
> import std.stdio, std.log;
>
> write("foobar"); // matches both std.stdio.write and std.log.write
>
> It'd also make it more difficult to tell what `write("foobar")` does,
> which is unacceptable for such a fundamental operation.

Solution is easy - don't do `import std.log` an don't recommend use to do it in docs, always use `import log = std.log`. This is how D module system is supposed to work.

Right now there two conflicting statements in language docs:
1) namespaces are not needed, modules should work as replacement
2) usage of plain imports is encouraged

Pretending that (1) is true and at the same time putting namespace workaround to the library is just lying to the programmers. Either we need to encourage programming style that works with D module system or admit it has completely failed. It is a problem not unique to std.logger

"Dicebot"  wrote in message news:slflceuaxmlsdsxzcsxc@forum.dlang.org...

> Solution is easy - don't do `import std.log` an don't recommend use to do it in docs, always use `import log = std.log`. This is how D module system is supposed to work.

It's easy, but it's not the easiest.  There is a lot of value in having the easiest way to do something also be the right way.