extern(C++, ns)

[Manu via Digitalmars-d]

On 20 January 2016 at 12:25, deadalnix via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Wednesday, 20 January 2016 at 02:15:27 UTC, Manu wrote:
>>
>> The C++ namespace semantic doesn't have a proper analogy in D, and the
>> D code is already organised into modules anyway making mirroring of
>> the C++ semantic irrelevant.
>> We don't mirror C/C++ semantics in other facets of the bindings, we
>> just make it link. There's no reason to deviate from that pattern
>> here.
>> Nobody seems to want to address the problem points I raise in my last
>> email though. If it was benign, I wouldn't care, but it causes way
>> more harm than good.
>
>
> What happens when one has conflicting symbols in 2 C++ namespaces ?

Put them in different modules.
Can you actually imagine a case in C++ where 2 symbols with the same
name are declared next to eachother under different namespaces in the
same place, such that they wouldn't be naturally divided into separate
modules in the first place?
This case appears to be the soul purpose of the design, and I'm trying
to convince that this is truly a very niche case, whereas the
situation we are in presents problems in the common case.
Workarounds should be required for the niche cases, not the common case.

> D's mapping of C++ namespaces could just mimic how import resolution work :
> allow qualified and unqualified access to the symbol when there is no
> conflict, forces you to use the qualified one when there (or to create an
> alias, or whatever).

It does work that way, and it's fine; it's no difference from if the
namespace weren't there at all... until you DO need to disambiguate
for some reason; the proposed point is to use ns.symbol, but you can't
in practise because ns is always in conflict with some other module,
so you have to use my.lib.ns.symbol. As soon as you must justify the
full name including the module, the namespace has failed at it's one
job. It may as well not be present.
That in itself is not a serious problems though, but the presence of
the namespaces do present other serious problems which are completely
unnecessary symptoms of the design, especially when you consider it
actually fails as it's only purpose in practise.
I mentioned problems in my prior post, and repeatedly before that, and
nobody has addressed any of them yet.