Voting: std.logger

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Fri Aug 1 18:19:57 PDT 2014


On 8/1/14, 6:08 PM, Dicebot wrote:
> On Friday, 1 August 2014 at 17:06:24 UTC, Daniel Murphy wrote:
>> "Dicebot"  wrote in message news:pnwgrcqfuhkzcaasatti at 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.
>
> If you find this important, you can always require renamed / static
> imports in your projects. On the contrary, if function name is already
> qualified with some redundant information, there is no simple way back
> other than aliasing all symbols from that module.
>
> I am convinced we are missing good style of using D import system, not
> good names.

To an extent I agree, but I have to side with the view that common 
artifacts in stdlib can cause quite some annoyance. I remember bug 
reports being made about clashing symbols between (I forgot exactly) 
std.string, std.regex, and std.algorithm. Clearly avoiding those clashes 
was all business as usual, but that doesn't mean we can't make things a 
tad better for standard library users.

Andrei



More information about the Digitalmars-d mailing list