On 20 January 2016 at 08:14, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > Oh what the hell. I'll answer it one last time: > > 1. C++ has namespaces. They went and invented a whole 'nother thing called > modules. Evidently not even they think that modules and namespaces are the > same thing.
You admit that modules supersede namespaces. We have modules, we use modules as standard practise. We don't need, or want, anything like namespaces. > 2. Multiple modules cannot have the same name in D. I'm not sure what situation you're imagining where modules would be created with the same names...? > C++ practice is to litter code with namespaces using the same name *. * among different includes... it is natural to reflect the C++ include tree as D modules, and this naturally gives everything expected scope separation. >From there, the only requirement is that we can link. > 3. Modules have ModuleInfos, static constructors/destructors, etc. These do > not make obvious sense for namespaces. I'm not sure why you're introducing these concepts...? This has nothing to do with name mangling. It has never been proposed that namespaces have anything to do with modules, only that modules make namespaces irrelevant. > 4. Modules and files have a 1:1 correspondence. This does not work for > namespaces. I'm not sure what your point here is. Are you arguing that C++ namespaces aren't expressible in D, because nothing can span modules? Of course, I agree completely. This is a good argument against trying to simulate C++ namespaces in D. > 5. "extern (C++) module std" ? Ugh. Where did you pull that from? Nobody has ever suggested anything like that as far as I know. Naturally, I strongly object to this too. > 6. Modules do not nest. Namespaces nest. I'm not quite sure how this is an argument, but if we're just making an analogy; modules nest within packages: import x.y.z; Organising the API into packages/modules is the business of the binding author. C++ namespace and/or header directory structure can be easily reproduced in a natural way as D modules. You seem to be approaching from the presumption that namespaces (or an awkward simulation of them) exist in D. These points are irrelevant if the namespace is just for mangling. > 7. Module semantics are independent of where they are imported. Not so for > namespaces. > > I.e. if modules were bludgeoned into being namespaces, Nobody has ever suggested anything like this. > there would be such a > list of special cases and confusions and exceptions and awkward crap you'd > be far, far better off having namespace as a SEPARATE feature, because > that's what they'd wind up being anyway, even if they were named "modules". If this is what you're thinking, you've misunderstood literally everything I've ever said on this topic. The feature should be nothing more than this: extern(C++, "ns") int x; x is mangled with "ns". Namespace is a string, no conflict with D names is possible, organisation and disambiguation is the business of the author. Everything past that is needless complexity and causes us problems. The extremely niche case where someone wants to declare 2 symbols with the same name within the same module (in C++, they achieve this using 2 namespaces), is easily solvable in various ways that a normal D user could use to resolve that desire in a pure D program, for instance (but not limited to) putting the second declaration in another module. _all consequent problems_ are abolished instantly, all behaviour is exactly like normal D code, no surprises, no edge cases. The code to do this must be a small fraction of the code required to implement the feature as it is today.
