DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Fri, 06 Apr 2012 20:25:23 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> DIP15 doesn't fix the explicit path problem though. You can't change
> std/algorithm.d into std/algorithm/ (with sorting.d, search.d, etc.)  
> without
> breaking code. You could make std/algorithm.d publicly import std/alg/*  
> and
> then DIP15 would allow you to import std.alg to get all of its  
> sub-modules,
> but you're still forced to use a module to publicly import symbols as  
> part of
> a migration path, and you can't split a module in place.

I think either you or I am missing something.

In DIP15, if you define std/algorithm/_.d, and then import std.algorithm,  
it imports std/algorithm/_.d, which then 1. publicly imports other  
modules, and 2. aliases symbols to the name std.algorithm.symbol.  At  
least, this is how I understand the intent.  It seems equivalent to me to  
the package.d proposal, it's just using _.d instead of package.d.

If you import std.algorithm.sorting, and try and use std.algorithm.sort,  
yes it will not work.  But this does not break existing code (which does  
not import std.algorithm.sorting), and I find it odd that we want to make  
std.algorithm.sort work if you don't import std.algorithm.

-Steve