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..