DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Fri, 30 Mar 2012 17:45:36 -0400, Michel Fortin
<michel.fortin at michelf.com> wrote:

> On 2012-03-30 14:46:19 +0000, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> 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