DIP16: Transparently substitute module with package

[Jonathan M Davis]

On Thursday, April 05, 2012 09:49:59 Steven Schveighoffer wrote:
> On Thu, 05 Apr 2012 09:23:25 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:
> > On 04/05/2012 02:58 PM, Steven Schveighoffer wrote:
> >> No, public imports simply mean that you can view the publicly imported
> >> module. It does *not* add aliases to the importing module.
> > 
> > Have you tried it?
> 
> I just did. OK, what the hell are we arguing about then?!
> 
> DIP16 is worksforme :)
> 
> See this part of the spec:
> 
> http://dlang.org/module.html
> 
> Read the part on public modules. You may understand why I didn't know
> about that "feature" (which seems to work on all the installed compilers I
> have, back to 2.033). I just read the public import part of TDPL, and
> there it is, all spelled out quite nicely. I'm going to file a bug
> against the spec... grrr...
> 
> I'm now firmly in the "we don't need to change anything, just refactor the
> modules and use public import" camp. We don't even need to change
> ANYTHING in the compiler! Forget everything I said before in this thread
> ;)
> 
> I suppose the only thing we don't get is being able to have a module and a
> package with the same FQN. I don't see that being a major issue.

What doesn't work is being able to turn a module into a package with the same 
name. Right now, we could create a std.alg package with sub-modules containing 
all of std.algorithm's functionality and change std.algorithm to pubicly 
import them all, but you can't turn std.algorithm itself into a package 
without breaking code. The package.d portion of the proposal makes it so that 
you can.

Now, public import's current behavior is _almost_ enough to make the second 
part completely unnecessary. The only change that would be required would be 
to make it so that std.algorithm.x looks in std/algorithm/package.d if there's 
no std.algorithm.x module, because otherwise the public imports in package.d 
would be putting all of the symbols in std.algorithm.package, not 
std.algorithm (that, and package.d isn't legal at present).

So, the whole point of this proposal - to seemlessly allow the transition of a 
module to a package in place - _does_ require a language/compiler change. But 
moving stuff from a module to a new package does work already.

- Jonathan M Davis