On 2012-04-02 13:04:31 +0000, "Steven Schveighoffer"
<[email protected]> said:
On Fri, 30 Mar 2012 17:45:36 -0400, Michel Fortin
The problem is that if .std.algorithm.package
contains a sort function and there is also a module called
std.algorithm.sort, the fully-qualified name of that 'sort' module wil l
become ambiguous. Moreover, whether the fully-qualified name
.std.algorithm.sort is ambiguous or not depends on what modules were
imported, which is not a very desirable behaviour.
So this becomes an error. I don't see this as a major problem. Just
don't name a module sort inside std/algorithm.
This is no different than ambiguous templates, which are allowed until y ou
want to instantiate one.
If you have ambiguous templates in the same module, it'll always be
ambiguous irrespective of what you import (and you can blame the
module's designer for it). If you have ambiguous templates residing in
different modules the symbol will be unambiguous until you've imported
the second module (same as overloaded functions). At that point you can
disambiguate using the fully-qualified name of the template (or
function).
Whereas if the fully-qualified name of a module becomes ambiguous
because of a symbol in another module, there is no way to disambiguate.
All you can do is avoid importing the two conflicting modules together,
just like when you encounter two headers trying to define the same
symbol in C/C++.
With the way D modules were designed, this cannot happen because you
can't have a module with the same name as a package. I always thought
this was done on purpose, but I might be wrong. Whatever we do, I think
it'd be a nice property to preserve that fully-qualified names should
always work.
--
Michel Fortin
[email protected]
http://michelf.com/
