DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Thu, 05 Apr 2012 08:49:24 -0400, deadalnix <deadalnix at gmail.com> wrote:

> If such a syntax is adopted, what would be the point of public imports ?  
> If it is still useful, then your syntax is a better choice, otherwise,  
> we'd better modify public import.

Another way to look at it:

A public import saves you from having to import dependent modules that you  
should be importing anyway.
A 'this' import treats the other modules as if they were actually part of  
the imported module in terms of namespace.

To give an example, std.range imports std.array.  std.array is a module  
all on its own, and has a specific set of functionality.  std.range has a  
different set of functionality, but you would never want to have std.range  
imported without also importing std.array.  Another example would be a  
derived class module publicly importing the base class module.

On the other hand, something like std.container could have 15 different  
container types in it.  Each of these container types should really live  
in their own module, in terms of maintenance and separation of private  
data.  For example, std.container.RedBlackTree has no business accessing  
the private members of std.container.Array.  But because they live in the  
same module, it can.  However, we don't want to define  
std.container.RedBlackTree.RedBlackTree in terms of namespace.  So we have  
one of these combining modules, and everything still lives in the  
std.container namespace, but we get all the benefits of separating the  
code into individual modules.

-Steve