On Friday, 1 August 2014 at 16:18:26 UTC, Daniel Murphy wrote:
> "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.

I am afraid we don't have the right way in D then. Caring about cross-module name conflicts feels too much like plain C.

On 8/1/14, 8:52 AM, Martin Nowak wrote:
> 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

Oh I hadn't realized that. Thanks! That strengthens my opinion that more work is needed on the library before inclusion in std.experimental. -- Andrei

On 8/1/14, 9:36 AM, Andrei Alexandrescu wrote:
> Oh I hadn't realized that. Thanks! That strengthens my opinion that more
> work is needed on the library before inclusion in std.experimental.

To clarify: I'm very strongly opposed to a design that requires rebuilding Phobos (or relying on different pre-built versions) for different logging levels. That's just unacceptable. User code must be able to set logging levels by just passing flags to their own builds.

Andrei

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

> I am afraid we don't have the right way in D then. Caring about cross-module name conflicts feels too much like plain C.

But with overloading!

It isn't just about avoiding conflicts - if the function name is unique, you can tell what the code is doing without having to examine the context so closely.  This is especially important for the standard library, because the time spent learning names can be reclaimed over multiple projects.

This is a strength of C, although C goes way too far with forcing it. 

Am Fri, 01 Aug 2014 09:43:32 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 8/1/14, 9:36 AM, Andrei Alexandrescu wrote:
> > Oh I hadn't realized that. Thanks! That strengthens my opinion that more work is needed on the library before inclusion in std.experimental.
> 
> To clarify: I'm very strongly opposed to a design that requires rebuilding Phobos (or relying on different pre-built versions) for different logging levels. That's just unacceptable. User code must be able to set logging levels by just passing flags to their own builds.
> 
> Andrei
> 

It's kinda awkward how complicated the D solutions are compared to C/C++ with the preprocessor. The only simple way in D seems to be using string mixins, but these look ugly on the user side.

On Friday, 1 August 2014 at 15:31:39 UTC, Martin Nowak wrote:
> It'd also make it more difficult to tell what `write("foobar")` does,
> which is unacceptable for such a fundamental operation.

Can you tell, what `log(1)` does?

On Friday, 1 August 2014 at 16:43:32 UTC, Andrei Alexandrescu wrote:
> On 8/1/14, 9:36 AM, Andrei Alexandrescu wrote:
>> Oh I hadn't realized that. Thanks! That strengthens my opinion that more
>> work is needed on the library before inclusion in std.experimental.
>
> To clarify: I'm very strongly opposed to a design that requires rebuilding Phobos (or relying on different pre-built versions) for different logging levels. That's just unacceptable. User code must be able to set logging levels by just passing flags to their own builds.

Must be able, but should it be the only possible way?

On 08/01/2014 07:10 PM, Kagamin wrote:
> On Friday, 1 August 2014 at 15:31:39 UTC, Martin Nowak wrote:
>> It'd also make it more difficult to tell what `write("foobar")` does,
>> which is unacceptable for such a fundamental operation.
>
> Can you tell, what `log(1)` does?

It returns 0. No, wait...

On 8/1/14, 10:23 AM, Kagamin wrote:
> On Friday, 1 August 2014 at 16:43:32 UTC, Andrei Alexandrescu wrote:
>> On 8/1/14, 9:36 AM, Andrei Alexandrescu wrote:
>>> Oh I hadn't realized that. Thanks! That strengthens my opinion that more
>>> work is needed on the library before inclusion in std.experimental.
>>
>> To clarify: I'm very strongly opposed to a design that requires
>> rebuilding Phobos (or relying on different pre-built versions) for
>> different logging levels. That's just unacceptable. User code must be
>> able to set logging levels by just passing flags to their own builds.
>
> Must be able, but should it be the only possible way?

Other ways would be also nice, but the primary use case is the user chooses the static logging level during build. -- Andrei

>
> Can you tell, what `log(1)` does?
>

Is there a irrefutable requirement to have a log function without explicit level?

Do we lose anything if we just force every log call to have a level, and dump the plain 'log' method?  Point people to use info if they don't care about the level, and you can clean things up considerably.

As for voting:

Qualified yes for std.experimental.  If experimental is supposed to be 'done but not baked' then this would be a no vote, in favor of a few more iterations with the dub package (and pointing people to use it).