On Tuesday, 31 July 2018 at 16:23:55 UTC, Manu wrote:
On Tue., 31 Jul. 2018, 3:40 am Jacob Carlborg via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

On 2018-07-31 10:12, Manu wrote:

> Given your favourite example:
> ----
> module a;
> extern(C++, ns) void foo();
> ----
> module b;
> extern(C++, ns) void foo();
> -----
> module c;
> import a, b;
> foo(); // error: ambiguous
> ns.foo(); // error, ambiguous (obviously)
> a.ns.foo(); // naturally, this works... it's the D module > that
> correctly organises the symbol. 'ns' is worthless here

This works:

a.foo();

You don't need "ns" in between the module name and the function.


Right... But did you miss the point? The D module does the organisation (as you show). The ns offers nothing and creates other kinds of problems. Just because name resolution traverses the namespace (in simple cases), there is an entire language of complexity that interacts with that name lookup, and as far as I know, it has never proven useful, but rather, only complicated and annoying leading to boilerplate and hacks in certain
situations. (ie, this thread exists and many others)

Can you give some examples of those certain situations? It would help clear what is wrong with how it is currently implemented.


One thing I don't like is that the C++ namespaces takes the name. So if you try to import a module that has C++ namespace of the same with the existing module, then you'll get an error. For effectively no reason, because as you say that namespace is useless and just occupies a name that could otherwise be used for the module name.

Reply via email to