On Fri, 30 Mar 2012 17:45:36 -0400, Michel Fortin
<[email protected]> wrote:
On 2012-03-30 14:46:19 +0000, Andrei Alexandrescu
<[email protected]> said:
Destroy!
Since you're asking…
One thing the current system avoids is unresolvable symbols. If two
symbol name clashes, you just qualify them fully and it'll always be
unambiguous. For instance:
.std.algorithm.sort(…)
Now, if std.algorithm becomes both a module and a package, you could
have both a sort function and a sort submodule with no way to
distinguish between the two, even when fully qualified. I think this is
why D does not allow modules to have the same name as packages.
I understand that you try to work around this problem by inventing a
.std.algorithm.package scope. Then you make it's content imported
automatically inside the .std.algorithm scope for backward compatibility
(and convenience). 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 will
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 you
want to instantiate one.
-Steve
