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.