I'm not sure what situation you're imagining where modules
would be created with the same names...?
How do you plan to map C++'s standard lib ? One giant hundred
of thousands of line C++ file ?
Surely it would map by file.
#include <vector> -> import stl.vector;
#include <map> -> import stl.map;
#include <string> -> import stl.string;
Perhaps 'stl' may be something else, 'std' is an unfortunate
conflict with phobos, but this is unique to this case.
But, in this case, I can't have an stl.vector!X which would map
to an std::vector<X> . The namespacing of symbol has been
completely changed.
I'd suggest it's the only possible way to make it feel the same.
It's a no-brainer for the binding author, copy and rename .h
files to
.d, then regex until finished.
That would require to have a similar namespacing, unless
extern(C++, name) introduce a symbol called name.
Note that the conflict rule can be tuned the same way it is
specified for multiple alias this and you get something really
nice.
What case is there where a C++ lib distributing its symbols
naturally
among modules named accordingly with the original include's
would
cause confusion when compared against the C++ docs?
Doc says '#include <libname/feature.h>', I'll 'import
libname.feature;'
Nothing could be more natural than this.
As a bonus, the project's C++ namespace 'libname' is already
present in the fully qualified name, it's the top level
package! No point repeating that as
'libname.feature.libname.symbol'.
I think it does make sense to make the C++ namespace "skippable",
alias this style, while keeping it around to disambiguate. It is
clear that C++ having namespacing and header being decoupled will
cause problem if namespaces do not introduce a symbol.
