On 18/12/13 22:40, Andrei Alexandrescu wrote:
2. Push imports from top level into the entities (functions, classes etc) that
use them.
This is probably going to be very productive. Example: a while back we had a
discussion about how std.stdio wound up pulling in std.complex. John Colvin
worked out that the module dependency goes something like this:
std.stdio -> std.algorithm -> std.random -> std.numeric -> std.complex
... so I looked a bit deeper and found that there are at least 2 points where
that dependency chain could be broken:
* std.algorithm relies on std.random I think only one actual function, namely
topN (where it calls std.random.uniform). All other uses of std.random are
inside unittests.
(Incidentally it's a bit bad that topN makes use of randomness but
does not AFAICS allow you to specify a RNG.)
* std.numeric relies on std.complex for quite a few functions and objects,
but by no means all, and I doubt that std.random's dependency on
std.numeric makes use of any of those. The problem here is that those
functions need awareness of std.complex.Complex at the module level, e.g.
because they have Complex return-types. So, it might be productive to
separate out std.numeric based on std.complex dependency.
I can provide a patch for std.random very easily (I already have it un-committed
on my system right now as a result of re-running the above analysis).
I also think it should be policy for Phobos that if an import is required only
for unittests, it must be imported in those individual unittests, not for the
module as a whole (and not in a version(unittest) block, which would disguise
the problem and cause failures between unittest release builds vs. release builds).
