On Sunday, July 29, 2018 6:10:01 AM MDT kinke via Digitalmars-d wrote:
> On Sunday, 29 July 2018 at 11:03:43 UTC, Jonathan M Davis wrote:
> > I guess that the argument at that point is that you would have to put them in separate D modules, just like you would if they were extern(D) functions.
>
> Yep, that'd sound acceptable to me, implying that
>
> ```
> extern(C++, cppns) { void foo(); }
> void foo();
> ```
>
> wouldn't work anymore, and particularly, this neither:
>
> ```
> extern(C++, cppns)
> {
>      extern(C++, nested) { void foo(); }
>      void foo();
> }
> ```
>
> so that a straight C++ namespace => D module hierarchy mapping would probably be required in the general case:
>
> ```
> // cppns/package.d
> module cppns;
> extern(C++, cppns) { void foo(); }
>
> // cppns/nested/package.d
> module cppns.nested;
> extern(C++, cppns) extern(C++, nested) { void foo(); }
> ```

Honestly, I'd expecting folks doing bindings for anything serious would be matching the layout of the C++ header files being translated. It becomes difficult to maintain bindings when their layout doesn't match the original files. Most of druntime's C bindings match the layout of the C headers that they're translating so that it's straightforward to find them (the primary exception being that OS-specific symbols from a standard header end up in a different file, which can be confusing and maybe shouldn't have been done, but those files follow the same layout - just in a different hierarchy under the OS's name). Anyone who didn't at least nominally make the layouts match would almost certainly run into maintenance problems in the long run.

- Jonathan M Davis

On Sun, 29 Jul 2018 at 01:30, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 7/29/2018 1:15 AM, Manu wrote:
> > All we're asking for is that C++ namespaces do **nothing** except affect the mangling.
>
> If I do that, the next bug report will be:
>
>    extern (C++, "ab") { void foo(); }
>    extern (C++, "cd") { void foo(); } // Error, foo() is already declared
>
>    foo(); // which one gets called?
>
> The reason namespaces were added to C++ is to not have such name collisions. Namespaces in C++ introduce a scope. D cannot interoperate with this without introducing a scope as well.

You're really reaching here. Of course, this error is legitimate and correct. Any D programmer knows they can't do this, and why would they expect they could?

There's no way you'll get a bug report from someone complaining they can't multiply define symbols in the same scope. That's common sense. They will intuitively move the second declaration into a second module. ...or they'll use your existing mechanism; it's in there now, we can't remove it.

But please support a variant where we can specify namespace as a string and opt-out of any funny business with scoping.

On Sun, 29 Jul 2018 at 04:04, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, July 29, 2018 2:28:08 AM MDT Walter Bright via Digitalmars-d wrote:
> > On 7/29/2018 1:15 AM, Manu wrote:
> > > All we're asking for is that C++ namespaces do **nothing** except affect the mangling.
> >
> > If I do that, the next bug report will be:
> >
> >    extern (C++, "ab") { void foo(); }
> >    extern (C++, "cd") { void foo(); } // Error, foo() is already declared
> >
> >    foo(); // which one gets called?
> >
> > The reason namespaces were added to C++ is to not have such name collisions. Namespaces in C++ introduce a scope. D cannot interoperate with this without introducing a scope as well.
>
> I guess that the argument at that point is that you would have to put them in separate D modules, just like you would if they were extern(D) functions.

Or extern(C), or extern(C++), or extern(ObjectiveC)...

On Sun, 29 Jul 2018 at 05:10, kinke via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> [...]
> so that a straight C++ namespace => D module hierarchy mapping
> would probably be required in the general case:
>
> ```
> // cppns/package.d
> module cppns;
> extern(C++, "cppns") { void foo(); }
>
> // cppns/nested/package.d
> module cppns.nested;
> extern(C++, "cppns") extern(C++, "nested") { void foo(); }
> ```

It's beautiful!

(but I added the quotes in there for you; without quotes is existing defined behaviour which introduces scopes)

On Sunday, 29 July 2018 at 08:28:08 UTC, Walter Bright wrote:
> On 7/29/2018 1:15 AM, Manu wrote:
>> All we're asking for is that C++ namespaces do **nothing** except affect the mangling.
>
> If I do that, the next bug report will be:
>
>   extern (C++, "ab") { void foo(); }
>   extern (C++, "cd") { void foo(); } // Error, foo() is already declared
>
>   foo(); // which one gets called?

mangle (C++, "ab") { void foo(); }
mangle (C++, "cd") { void foo(); } // Error, foo() is already

That would not require any changes to extern and there would be no sensible argument for trying to define foo twice.

On Sunday, 29 July 2018 at 08:28:08 UTC, Walter Bright wrote:
> On 7/29/2018 1:15 AM, Manu wrote:
>> All we're asking for is that C++ namespaces do **nothing** except affect the mangling.
>
> If I do that, the next bug report will be:
>
>   extern (C++, "ab") { void foo(); }
>   extern (C++, "cd") { void foo(); } // Error, foo() is already declared
>
>   foo(); // which one gets called?
>
> The reason namespaces were added to C++ is to not have such name collisions. Namespaces in C++ introduce a scope. D cannot interoperate with this without introducing a scope as well.

FYI: this doesn't error as of now, but with https://github.com/dlang/dmd/pull/8429 it will.

On 7/29/2018 1:52 PM, Manu wrote:
> On Sun, 29 Jul 2018 at 05:10, kinke via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> [...]
>> so that a straight C++ namespace => D module hierarchy mapping
>> would probably be required in the general case:
>>
>> ```
>> // cppns/package.d
>> module cppns;
>> extern(C++, "cppns") { void foo(); }
>>
>> // cppns/nested/package.d
>> module cppns.nested;
>> extern(C++, "cppns") extern(C++, "nested") { void foo(); }
>> ```
> 
> It's beautiful!
> 
> (but I added the quotes in there for you; without quotes is existing
> defined behaviour which introduces scopes)
> 

But that works now, I suggested it, and you didn't find it acceptable !!?!!

On 7/29/2018 1:45 PM, Manu wrote:
> There's no way you'll get a bug report from someone complaining they
> can't multiply define symbols in the same scope. That's common sense.

But then you cannot interface with this C++ code:

    namespace ab { void foo(); }
    namespace cd { void foo(); }

Why would you find this acceptable?

On 7/29/2018 2:44 PM, Seb wrote:
> FYI: this doesn't error as of now,

Right, but also you cannot specify which will be called.

On 7/29/2018 1:52 PM, Manu wrote:
> On Sun, 29 Jul 2018 at 05:10, kinke via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> [...]
>> so that a straight C++ namespace => D module hierarchy mapping
>> would probably be required in the general case:
>>
>> ```
>> // cppns/package.d
>> module cppns;
>> extern(C++, "cppns") { void foo(); }
>>
>> // cppns/nested/package.d
>> module cppns.nested;
>> extern(C++, "cppns") extern(C++, "nested") { void foo(); }
>> ```
> 
> It's beautiful!

You must have missed my other post:

====================================================

Here's another method:

------
extern (C++, ns) { int foo() { return 1; } }

mixin template X()
{
  extern (C++, ns) { int bar() { return 2; } }
}

mixin X!() x;

-------

and another:

-----
extern (C++, ns) { int foo() { return 1; } }

struct S
{
  extern (C++, ns) { int bar() { return 2; } }
}
----