On Friday, 28 February 2014 at 12:59:32 UTC, Mike Parker wrote:
Ideally one should use modules as namespaces :P
I don't buy that. That works fine to resolve conflicts, but it
doesn't work for fine-grained namespace management. And when
using named imports, that means everything in the module then
belongs to that namespace, which isn't at all what I want.
Besides which, using either fully-qualified names or named
imports puts the impetus on the caller. If I design my modules
around namespaces with the understanding that the caller will
type foo.bar.myfunc all the time, there are bound to be
conflicts when they forget to do it.
D design is based on module as smallest composition unit. If you
find yourself in situation where you want to have two namespaces
in a single module, you should split it into two modules.
Putting impetus on caller (named imports) is good here and huge
advantage over C++ way in my opinion. It gives more control over
application naming scheme.
On the other hand, by wrapping my namespaced stuff in structs
or classes, I can have multiple namespaces per module, some
things completely outside the namespace, and the user gets a
compiler error if they don't use it. To me, that's much, much
neater.
It simply does not fit with D type system, most importantly with
accessiblity attributes. I'd hate to encounter all that you
mention as "benefits" in some D library I am forced to use.
