On Thursday, April 05, 2012 09:49:59 Steven Schveighoffer wrote: > On Thu, 05 Apr 2012 09:23:25 -0400, Timon Gehr <timon.g...@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
