extern(C++, ns)

[deadalnix via Digitalmars-d]

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