DIP16: Transparently substitute module with package

[Michel Fortin]

On 2012-04-05 00:50:49 +0000, Michel Fortin <michel.fortin at michelf.com> said:

> I think we need a third option.
> 
> Here's an idea: we could allow modules having a single symbol with the 
> same name as the module to behave as if they were the symbol itself, 
> just like templates behaves. For instance:
> 
> 	module std.algorithm.sort;
> 
> 	void sort(int[] t);
> 
> Now you can import std.algorithm.sort and then use the 
> std.algorithm.sort fully qualified name as if it was a function, even 
> though it's the module name (std.algorithm.sort.sort would be the 
> function's name).
> 
> Or maybe we could just allow "alias sort this" at module level? Or is 
> it allowed already?

Forgot to follow through with what "import std.algorithm" would do.

If std.algorithm is a package, then it should only contain modules 
(which can each pose for a function/class/struct/variable thanks to the 
feature described above). Importing the package std.algorithm would 
open the std/algorithm.d file, read a list of package from the file, 
and proceed to import each of them (just as if you'd have imported each 
of them separately).

Here is an idea for declaring the list of modules to import when you 
import a package in std/algorithm.d:

	package std.algorithm;

	module std.algorithm.sort;
	module std.algorithm.map;
	...

(I'm _not_ using a package.d file because that'd incur two lookups: one 
for std/algorithm.d in case it's a module, and one for 
std/algorithm/package.d in case it's a package. It also removes the 
possibility of both files existing at the same time which would be 
confusing.)

This way, modules and packages stay exactly the same in the language as 
they are now, except that you can now import a package directly instead 
of importing each module separately. And modules with a single symbol 
with the same name as the module are treated as if they were that 
symbol. This allows migrating a module to a package without breaking 
the existing code base, but the drawback is that each symbol in the 
module becoming a package need to become its own submodule.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/