On 20 January 2016 at 12:25, deadalnix via Digitalmars-d <[email protected]> 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.
