On 4/2/2014 7:14 PM, Michel Fortin wrote:
On 2014-04-03 01:09:43 +0000, Walter Bright <newshou...@digitalmars.com> said:
I considered that, but it fails because:
C++:
namespace S { namespace T {
int foo();
namespace U {
int foo();
}
} }
D:
extern (C++, S.T) {
int foo();
extern (C++, U) {
int foo();
}
}
foo(); // error, ambiguous, which one?
S.T.foo(); // S undefined
That's a contrived example.
Not at all. The whole point of using namespaces in C++ is to introduce a scope.
And the whole point of scopes is to have the same name in different scopes
represent different objects.
Perhaps I'm wrong, but I'd assume the general use
case is that all functions in a module will come from the same C++ namespace.
I believe that is an incorrect assumption. C++ namespaces were specifically (and
wrongly, in my not so humble opinion, but there it is) not designed to be
closed, nor have any particular relationship with modules.
For the contrived example above, I think it's fair you have to use a contrived
solution:
I don't believe that punishing C++ users who dare to try D is the path to
success for D :-)
Alternatively you can use another module for the other namespace.
Forcing C++ code that exists in a single file to be split up among multiple D
files is inflicting unnecessary punishment on the poor guy trying to justify
migrating to D.
