DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Mon, 02 Apr 2012 20:44:09 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> 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++.

How does this happen?  The FQN cannot be ambiguous.

For example, if we change std/algorithm.d into:

std/algorithm/sorting.d which defines sort
std/algorithm/finding.d which defines find
std/algorithm/package.d which imports sorting.d and finding.d

Then how can importing some other module make the FQN ambiguous?  The FQN  
for sort is std.algorithm.sorting.sort.  Now, if you define the symbol  
sort inside std/algorithm/package.d, you have an ambiguity, but so what?   
If you are responsible for the std.algorithm module, aren't you  
responsible for all the files in that pseudo-package?  I don't see how it  
changes things from today.  Basically, my point is the only ambiguity FQN  
in the package.d file can create is with other symbols within that same  
directory, therefore within the same module.

All we have to do is adopt the practice that phobos' package.d will only  
publicly import other modules.  It won't define any symbols.  Then there  
will always be an unambiguous FQN.

Hm... maybe you mean if you can have std/algorithm/package.d do something  
like import std.file, which contains another sort function, is that now  
packaged under std.algorithm.sort?  I don't think that's possible in the  
given DIP.

-Steve