DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Thu, 05 Apr 2012 11:23:12 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 4/5/12 7:43 AM, Steven Schveighoffer wrote:
>> I currently think DIP16 is invalid/worksforme (public imports allows
>> splitting a module into a package). All that is left is how we could
>> specifically import a package with one import statement.
>
> Not entirely (I was aware of the way public import works). An issue does  
> exist - there are "too many names", i.e. the alias pulled in the  
> importing module and also the name being imported. This makes for odd  
> synonyms such as std.algorithm_package.sort.sort being the same as  
> std.algorithm.sort.

Right, but if one only ever imports std.algorithm, who cares what the  
submodule FQNs are?

AIUI, DIP16 also doesn't really reduce the number of names either.

> The other issue is that obviously algorithm_package and algorithm must  
> have distinct names, which makes the scheme a bit awkward at least until  
> we define a compelling convention. I guess we can live with all that.

Agreed.  I think Don mentioned std.math already does something, we may  
want to look at that model.

A couple issues that still need consideration:

1. If std.algorithm the module becomes std.algorithm the package, what  
happens with ddoc?  We probably *do* need a compiler solution to this.
2. deadalnix pointed out that if we come up with a scheme where the  
package module and its submodules are in the same directory, the package  
accessibility qualifier can be used (hey look, a use for the package  
keyword!).

-Steve