DIP16: Transparently substitute module with package

[Michel Fortin]

On 2012-04-02 13:04:31 +0000, "Steven Schveighoffer" 
<schveiguy at yahoo.com> 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
michel.fortin at michelf.com
http://michelf.com/