On Mon, 28 Apr 2014 10:50:09 -0400, Byron <byron.he...@gmail.com> wrote:
On Mon, 28 Apr 2014 10:45:14 -0400, Steven Schveighoffer wrote:
On Mon, 28 Apr 2014 10:37:36 -0400, Byron <byron.he...@gmail.com> wrote:
why not import _cpp = bar; ?
That doesn't help. foo.func() is still ambiguous. With this proposal,
you have hijacked the meaning of namespace lookup. When I say x.y.z, it
doesn't just mean look for symbol z in module x/y.d, it can also mean to
look for symbol z in C++ namespace x::y. This was not the case with C
binding, which continued to use D modules for symbol lookup.
Consider that a boatload of C++ code is named std::something. Now,
std.string has an ambiguous meaning wherever it is used!
-Steve
bar is renamed, thus you have to access via _cpp.[namespace]
renames were added to prevent hijacking.
That renames the bar module, but not the foo C++ namespace, which can be
assumed when calling foo.func.
In reality, you could "fix" the situation by renaming the foo D module,
and then foo.func would unambiguously refer to bar's func :)
Another alternative fix would be to allow renaming C++ namespaces. I
strongly recommend against that. The better alternative is to reserve
qualified name lookup to D modules alone. Adding a mechanism that is
possibly ugly, but that does NOT conflict with module lookup, in order to
disambiguate C++ symbols is fine.
-Steve
