On 18/01/2016 6:47 AM, Walter Bright wrote:
> On 1/17/2016 3:55 AM, Daniel Murphy wrote:
>> So now we have two public symbols called 'mylib', and because they
>> conflict they
>> can't be used to disambiguate eg 'someotherlib.funca' with
>> 'library.a.funca'.
>
> Consider these two C++ files:
>
> ------file 1-------------
> namespace (X) { int fooa() { ... }
> ------file 2-------------
> namespace (X) { int fooa() { ... }
> -------------------------
>
> You'll get a multiply defined symbol error for X.fooa() from the linker.
> When using namespaces in D, the "one definition rule" needs to be
> followed just as in C++ for the same reason.
>
> However, in D, you CAN do the following:
>
> -----module M-----------
> extern (C++,X) { int fooa(); }
> -----module N-----------
> extern (C++,X) { int fooa(); }
> ------------------------
>
> and yes, M.X.fooa() will wind up referring to the same externally
> defined symbol X::fooa() as N.X.fooa().
>
> Because, as I said multiple times, namespaces in D affect the name
> mangling in a C++ way while doing symbol lookup in the D way.
>
> Note that
>
> extern(C) { ... }
>
> in D works EXACTLY the same way.
So???? Why make extern(C++, namespace) introduce a new symbol? Why not
just let it change ONLY mangling and use modules to organize symbols and
resolve conflicts?
