Suggestion - use local imports in Phobos

[Idan Arye]

One of Phobos' design goals was internal modularity. As Walter 
mentioned in another 
thread(http://forum.dlang.org/thread/kojnq5$2qst$1...@digitalmars.com#post-kok6q3:24jen:241:40digitalmars.com), 
this goal has been greatly compromised. A long list of imports is 
a common sight in the heads of Phobos' source files. This, 
ofcourse, is done for a good reason - we all know the benefits of 
DRY.

The advantages for internal modularity, as written in the Phobos 
readme(=`index.d`), are:

 1) "It's dis­cour­ag­ing to pull in a megabyte of code bloat by 
just try­ing to read a file into an array of bytes."
 2) "Class in­de­pen­dence also means that classes that turn out 
to be mis­takes can be dep­re­cated and re­designed with­out 
forc­ing a rewrite of the rest of the class li­brary."

The second advantage comes in direct conflict with the DRY 
principle - if Foo is to enjoy bug fixes in Bar, Foo must also 
suffer from breaking changes in Bar. Also a change that breaks 
library code will probably break user code as well, so those 
changes are discouraged anyways.

As for the first advantage, I believe it can be achieved with 
local imports.

Many modules import other modules solely for usage in unit tests. 
Those imports are redundant if you don't unit-test Phobos - and 
most projects written in D don't run the standard library unit 
tests. If those imports were local to the unit test, they 
wouldn't be imported in outside code.

Also, a huge portion of Phobos is written in templates. If an 
import is local to a template, and the template is not 
instantiated, then the module is not imported.

Due to these characteristics of Phobos, I believe making the 
imports local to the unit tests and templates that use them will 
reduce the number of imports the compiler has to do.


Another advantage of making the imports local(whenever possible) 
is that it would make it easier to remove imports. Currently, if 
a change to an implementation in Phobos removes it dependency on 
a module, you can't remove them module's name from the import 
list, because maybe some other part of this module needs that 
import. If that import was local to the implementation that used 
it, you could remove the import safely, knowing that if it is 
needed somewhere else, it is imported locally there.


One big disadvantage of this suggestion is that implementing it 
is a tedious job - like I said, Phobos has many templates, so the 
compiler won't alert us about a missing module unless we 
instantiate the template that needs it - and some templates can 
have multiple "instantiation paths", that some of them might not 
use the module!

So, we will have to scan the source files manually to determine 
which section requires which modules. Luckily, this change is not 
needed to be done at once, since it is not a breaking change, and 
should not affect user code(though it will make Phobos pull 
requests harder to merge).


Also, I'm not really familiar with the internals of dmd - how 
much impact will importing the same module many times have on the 
compilation performance? Will it be more or less than what we 
save by reducing the number of imported modules?


Opinions?