Naming conventions for functions in similar modules

[Andrej Mitrovic]

Yeah I'm getting a little tired of naming clashes. I'm not a fan of
having to use "std.module" in front of every function call that has
name clashes.

Let's say I have a lot of code and want to use some symbol, but I get
name clashes. One workaround is to use selective imports, but this
can't work with existing code. Say I have this:

import std.foo;
import std.bar;

and I try to use some symbol "doo" from std.bar which is defined in
both modules. Selective imports don't help at all in this situation,
because:
import std.foo;
import std.bar : doo;

Now all other symbols I happen to use from std.bar are missing, and
the wall of compiler errors kicks in.

So then the alternative is to do:
import std.foo;
import std.bar;
alias std.bar.doo doo;

But this is *tedious* to do every time there's name clashes. It gets
worse when there's new additions or changes in phobos which introduce
more naming clashes, then you have to change your entire codebase if
you want to upgrade.

Using static imports also doesn't scale if you already have code that
uses std.bar:

import std.foo;
static import std.bar;  // woops, now we have to prepend std.bar
                                // for every single symbol from this module

And the 4th alternative is to only call conflicting symbols explicitly:

import std.foo;
import std.bar;
std.bar.doo();

I'm in favor of avoiding introducing additional name clashes. And I'm
quite fond of having struct wrappers around related functionality. For
example the GC struct in core.memory is great, I'll never mistake a C
malloc with a GC malloc in code. But if I had to use std.GC.malloc,
then that's a bit too much for me.

Another example is std.parallelism.taskPool. It's nice to see code like this:
taskPool.reduce!"a + b * b"(0.0, nums);

I'll never mistake that for std.algorithm.reduce. And it's not too hard to type.

Someone mentioned that we shouldn't use structs as name wrappers
because that's against "D's philosophy" and it's working around the D
module system. Well, the D module system might do a great job at
protecting function hijacking, but wasting programmer time on name
clashes could be as frustrating as hunting down a function hijack in
some /lesser/ module system.

That's my 2 cents..