On Monday, 30 November 2015 at 07:45:54 UTC, Walter Bright wrote:
>> Why not produce something similar to an overload set for C++ namespace ? An
>> error needs to be issued only if X or Y is duplicated, otherwise, this is fine.
>
> Because I'd rather have symbol table lookups done in a consistent manner, rather than special casing it everywhere. The above behavior is completely consistent with how everything else works, because it uses the exact same code.

The proposed behavior is also not new (as per spec, alas it doesn't work in DMD), as it is the same as for multiple alias this.

On Sunday, 29 November 2015 at 04:57:28 UTC, Walter Bright wrote:
> We considered making them for mangling only, and rejected it as unworkable, because then two identical names in different namespaces could not be distinguished by the D symbol table system.

Didn't you show how two identical names can be distinguished with D symbol table system:

On Sunday, 29 November 2015 at 18:29:14 UTC, Walter Bright wrote:
>     file1.NS.X x;
>     file2.NS.Y y;

It also works the same for C bindings: they share (empty) namespace, but identical C declarations can be distinguished in D if they are in different modules. Maybe it's better to ignore C namespaces and rely on D module system instead?
Though I don't know why one would want to disallow access to a C++ namespace.

On Sunday, 29 November 2015 at 11:13:03 UTC, Ola Fosheim Grøstad wrote:
> On a related note, does D support inline namespaces? Apparently it affects mangling:
>
> http://stackoverflow.com/questions/29764869/can-inline-namespaces-be-used-to-keep-backwards-compatibility-in-a-shared-librar
>
> I use inline namespaces quite a bit and am curious of how D resolves those.

I wish someone would shed som light on this as inline namespaces is what libraries will use in the future in order to do versioning and  target different architectures, the one marked "inline" is made active and can be directly accessed through "X::decl" or "X::version1::decl" in c++:

namespace X {
     inline namespace version1 {
          decl....
     }
     namespace version2 {
          decl....
     }
}

Seems to me that D needs to embed clang and that the current bindings-only approach will not survive C++11 and later standards.

On 30 November 2015 at 20:12, Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 29 November 2015 at 04:57:28 UTC, Walter Bright wrote:
>>
>> We considered making them for mangling only, and rejected it as unworkable, because then two identical names in different namespaces could not be distinguished by the D symbol table system.
>
>
> Didn't you show how two identical names can be distinguished with D symbol table system:
>
> On Sunday, 29 November 2015 at 18:29:14 UTC, Walter Bright wrote:
>>
>>     file1.NS.X x;
>>     file2.NS.Y y;
>
>
> It also works the same for C bindings: they share (empty) namespace, but
> identical C declarations can be distinguished in D if they are in different
> modules. Maybe it's better to ignore C namespaces and rely on D module
> system instead?
> Though I don't know why one would want to disallow access to a C++
> namespace.

Exactly, the D module system would still be in place. Assuming they were in defferent modules, then the D module system would keep them out of conflict naturally, with rules identical to the normal D rules. I imagined this; C++ namespace is for mangling, D module is for scoping. That's not how it seems to be, so my intuition was dead wrong, but my weekend's experience has convinced me it would be better how I initially intuited. Thing is, we're presenting a C++ API to D, so we want to present it in D's terms, that is, the API is distributed among D modules in a way that makes sense to a D user. I don't want to present the API in C++ terms, and it's not even practical; stuffing the entire C++ API into a single D module is crazy. In the cases I'm interested in, the C++ API is possibly larger than the entire D codebase that's attached to it.

Walter said this: "Stop trying to bash D into behaving like C++! [...]", which I was kind of offended by, because it couldn't have been further from my intent. I'm trying to bash C++ into behaving like D, and the best way to do that would be to say that C++ namespace is for mangling only, and expect that the dev will distribute the C++ symbols among D modules in such a way that makes sense to D developers consuming the API.

On 29 November 2015 at 22:58, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 29 November 2015 at 12:39:14 UTC, Joseph Rushton Wakeling wrote:
>>
>> On Sunday, 29 November 2015 at 04:57:28 UTC, Walter Bright wrote:
>>>
>>> Aliases do not change access permissions. They are just aliases.
>>
>>
>> Note that this is a problem beyond Manu's use-case.  Example: subtyping via alias this currently requires the alias'd entity to be public, contra the example given on TDPL p.231 (see https://issues.dlang.org/show_bug.cgi?id=10996 for details).
>>
>> This means that to use subtyping in practice requires internal implementation details to be revealed to the user, which isn't very nice :-(
>
>
> As long as aliases effectively disappear in the compiler once a replacement has been made, and they don't end up in error messages, allowing aliases to muck with anything about the original symbol seems like a recipe for disaster, though I can certainly see why folks would want it (and arguably, it would be a lot more user-friendly if the aliases showed up in the error messages along with the original symbol rather than outright disappearing).
>
> - Jonathan M Davis

This. This is my experience with aliases too. I have found disappearance of aliases has been a source of confusion on numerous occasions.

On 11/29/2015 12:13 PM, Ola Fosheim Grøstad wrote:
> On a related note, does D support inline namespaces? Apparently it
> affects mangling:
>
> http://stackoverflow.com/questions/29764869/can-inline-namespaces-be-used-to-keep-backwards-compatibility-in-a-shared-librar
>

Namespaces affect mangling. The inline keyword doesn't.

>
> I use inline namespaces quite a bit and am curious of how D resolves those.
>
>

string inlineNamespace(alias ns)(){
    string s;
    foreach(m;__traits(allMembers,ns))
        s~=`alias `~m~`=`~__traits(identifier,ns)~`.`~m~`;`;
    return s;
}

extern(C++,std){
    extern(C++,version1){
        void bar(){}
    }
    mixin(inlineNamespace!version1);
    extern(C++,version2){
        void bar(){}
    }
}

On Monday, 30 November 2015 at 14:22:17 UTC, Timon Gehr wrote:
> On 11/29/2015 12:13 PM, Ola Fosheim Grøstad wrote:
>> On a related note, does D support inline namespaces? Apparently it
>> affects mangling:
>>
>> http://stackoverflow.com/questions/29764869/can-inline-namespaces-be-used-to-keep-backwards-compatibility-in-a-shared-librar
>>
>
> Namespaces affect mangling. The inline keyword doesn't.

The problem is that the inlined namespace can change without affecting C++ code. That makes it difficult to make stable bindings for D as it is transparent in C++, but non-transparent in D. Right?

On 11/30/2015 2:26 AM, Ola Fosheim Grøstad wrote:
> I wish someone would shed som light on this as inline namespaces is what
> libraries will use in the future in order to do versioning and  target different
> architectures, the one marked "inline" is made active and can be directly
> accessed through "X::decl" or "X::version1::decl" in c++:
>
> namespace X {
>       inline namespace version1 {
>            decl....
>       }
>       namespace version2 {
>            decl....
>       }
> }
>
> Seems to me that D needs to embed clang and that the current bindings-only
> approach will not survive C++11 and later standards.


It'd be worthwhile to learn how D's name lookup system works before declaring it lame and insufficient:

  extern (C++, X) {
        extern (C++, version1) {
                enum e = 3;
        }
  }

  int x = e;
  int y = X.e;
  int z = X.version1.e;

compiles successfully.

On 11/30/2015 3:42 AM, Manu via Digitalmars-d wrote:
> That's not how it seems to be,

Are you still not understanding how name lookup works in D?

(You won't be the first. I explain it to people over and over, and nobody gets it. I have no idea why it is so hard to understand.)

C++ namespaces introduce scopes. The normal D lookup rules for scoped names applies. When names in C++ namespaces are mangled, they are mangled like C++ names would be, not like D names would be.

Lookup rules, apply one by one until found:

1. Look up in current scope.
2. Look up in imported scopes. Error if more than one is found.
3. Go up a level, and goto 1.

On 11/30/2015 3:42 AM, Manu via Digitalmars-d wrote:
> Exactly, the D module system would still be in place. Assuming they
> were in defferent modules, then the D module system would keep them
> out of conflict naturally, with rules identical to the normal D rules.
> I imagined this;

No need to imagine:

"Namespaces create a new named scope that is imported into its enclosing scope."

    -- http://dlang.org/spec/attribute.html#namespace

> C++ namespace is for mangling, D module is for
> scoping. That's not how it seems to be, so my intuition was dead
> wrong, but my weekend's experience has convinced me it would be better
> how I initially intuited.

What about:

    file1.NS.X x;
    file2.NS.Y y;

?