phobos dependencies

[Joseph Rushton Wakeling]

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).