extern(C++, ns)

[Manu via Digitalmars-d]

On 20 January 2016 at 18:37, deadalnix via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Wednesday, 20 January 2016 at 07:51:27 UTC, Manu wrote:
>>>
>>> 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.
>>
>
> Maybe you don't, but I remain quite confident that being able to mimic the
> structure of the C++ code in D is valuable. One can create a binding for a
> library and have it usable in a similar fashion as it is in C++ from D.

How is that not possible with normal use of modules?

> This makes it nice to people that already know the library, reduce the need
> for specific doc for the binding, and makes maintenance of the binding much
> easier as it has the same structure as the mapped C++ lib.

I'm not sure how maintaining this structure has anything to do with namespaces.
The only requirement for a lib to feel natural is to map each header
to a module of the same name.

When I look up the qt doc, I see:
  #include <widget.h>

Which intuitively maps to:
  import qt.widget;


The author requires some latitude in such mapping, eg:
  #include <SDL_image.h>
Obviously unsavoury in D mapped verbatim, it would likely become:
  import sdl.image;

You may consider this a drastic deviation from the doc, but I expect D
users would universally prefer this.

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

>>> 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.
>>
>
> You did that quite a few time yourself.

No, I really *really* didn't.
It seems I have a habit of being completely misunderstood.

> The WHOLE point of namespace in C++ is to be able to have symbol with the
> same name and not conflict.

D is extremely good at this already.

> Now you could say, put them in different modules and use the modules to
> disambiguate, but then you'd use the C++ library in quite a different way,
> meaning you need to write new doc and make the work of the binding
> maintainer harder.

This doesn't make sense at all. How is that using it in a completely
different way?
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.

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