extern(C++, ns)

Manu via Digitalmars-d digitalmars-d at puremagic.com
Tue Jan 19 05:56:54 PST 2016


On 19 January 2016 at 18:54, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 1/19/2016 12:42 AM, Daniel Murphy wrote:
>>
>> 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?
>
>
> 1. Because a namespace is a scope, and is expected to act like one.

There is absolutely no such expectation. Please take a poll of
interested parties if you want to make this argument.

> 2. So names in different namespaces will not conflict.

Instead, the namespaces themselves conflict... in every single module!
Worse yet, they tend to conflict with the top-level package name,
which is terminal for the design.

You're taking one extremely unlikely possibility with a simple and
obvious solution, and replacing it with a situation where there is
conflict in every single module. ns.symbol isn't a useful statement
since ns is always in conflict, necessitating x.y.ns.symbol. The
necessary disambiguation via full module name justification makes the
redundancy of the namespace plain, but we gain such awkward problems
in its wake:
 * namespace names conflict with the D top-level package name (expect,
vast majority of cases)
 * there is more than 1 module (expect, vast majority of cases)
 * namespace names conflict with D keywords
 * scanning meta code now needs new tricks to recurse into namespaces
(are there __traits even available for this?)
 * existing/established reflection meta fails when namespaces are
present, requires otherwise unnecessary retrofit with additional logic

As soon as you must prefix 'x.y' (very likely), the namespace has
completely failed at its soul task, and remains nothing more than a
nuisance.

Let us opt-in if you want this behaviour. It shouldn't be default.

> 3. So names in namespaces can be referenced as:
>
>     std.exception
>
> as one would expect.

Except this rarely works. This expression fails because namespaces
require full module justification (ie,
stdcpp.exception.std.exception), since they are virtually always in
conflict. This behaviour is NOT what one would expect, and can only
lead to annoyance or confusion.
C++ namespaces span entire projects, they aren't self-contained in
individual modules. So, namespace conflict is certain; I invoked it
within seconds of attempting to use this feature, whereas the niche
case the whole design attempts to prevent is extremely unlikely; I've
never encountered it in my career as a C++ programmer.

You have presented no other justification for the design than an
extremely unlikely case with a trivial workaround, and instead forced
that we require various other horrible workarounds as consequence
which are almost guaranteed to occur. How can you possibly balance
this design decision?

C++ namespaces aren't like a D scope, they're more like a D package.
There's not a separate instance of the C++ namespace in each object
file, there's just one that spans the whole project, just like the
top-level package name in D which all modules beneath are a member of.

> As the length of this thread testifies, this has been discussed at length
> already.

No it hasn't. I don't feel like it's been discussed at all.
I've explicitly asked both you and Andrei to justify the design
several times, no less than 5, and you haven't responded a single time
other than repeating these same points without providing any support
or evidence.
Andrei deliberately dodged the request, replying with something like
"the best way to move forwards is to present code that demonstrates
bugs". Neither of you appear to be willing to engage in discussion
relating to the design, or how it's flawed and pointless.
It looks like you understand there's no objective justification for
the design. I suspect you just don't want to change it now it's in.


More information about the Digitalmars-d mailing list