phobos dependencies

[Joseph Rushton Wakeling]

On 20/12/13 10:06, Meta wrote:
> 2 comes with its own problems, though. With imports at the top, you can easily
> tell what the module imports at a glance. Putting imports into the deepest
> possible scopes where they are used will make it a huge chore to hunt all the
> imports down. You can of course grep for "import" (or ctrl+f for more plebeian
> editors), but you still don't have that singular list in one place that you can
> easily look at to tell what the module imports.

Conversely, one problem of imports at the top is that it's easy for unnecessary 
imports to hang around just because you don't have a direct association between 
the import and what it's actually used for.

I think the real issue we face is that it's not possible to really gain the 
advantages of deeply-nested-as-possible imports without _also_ breaking up the 
modules; we can't have Andrei's strategy (2) without some of strategy (3). 
Example: std.algorithm.topN, the only part of std.algorithm (apart from 
unittests) that requires std.random:

     void topN(alias less = "a < b",
             SwapStrategy ss = SwapStrategy.unstable,
             Range)(Range r, size_t nth)
         if (isRandomAccessRange!(Range) && hasLength!Range)
     {
         static assert(ss == SwapStrategy.unstable,
                 "Stable topN not yet implemented");
         while (r.length > nth)
         {
             auto pivot = uniform(0, r.length);
             // ... etc. ...
         }
     }

Now, at first glance it's easy to just insert an extra line before "auto pivot = 
...":

     import std.random : uniform;

... but it quickly becomes non-trivial if you want to do what really ought to be 
an option here, and allow a non-default RNG to be passed to the function:

     void topN(alias less = "a < b",
             SwapStrategy ss = SwapStrategy.unstable,
             Range, RandomGen)(Range r, size_t nth, ref RandomGen rng)
         if (isRandomAccessRange!(Range) && hasLength!Range
             && isUniformRNG!RandomGen)  // <--- needs std.random.isUniformRNG
     {
         static assert(ss == SwapStrategy.unstable,
                 "Stable topN not yet implemented");
         while (r.length > nth)
         {
             auto pivot = uniform(0, r.length, rng);
             // ... etc. ...
         }
     }

     // New function to support old 2-parameter version using default RNG
     void topN(alias less = "a < b",
             SwapStrategy ss = SwapStrategy.unstable,
             Range)(Range r, size_t nth)
         if (isRandomAccessRange!(Range) && hasLength!Range)
     {
         topN(r, ss, rndGen);    <---- needs std.random.rndGen;
     }

The second of the two needed imports is easy and can be nested inside the 
function, but the first -- the isUniformRNG template -- requires the import in 
the module's own scope.

So, to really allow std.algorithm to do away with its dependency on std.random, 
you need to break isUniformRNG and similar templates away from the rest of the 
std.random functionality.

(Yes, I know, you could break topN out from the rest of std.random, but remember 
that topN itself is only dependent on std.random for the case where you're using 
the unstable swap strategy.)

I'd hypothesize that probably it would be productive to start modularizing 
Phobos modules by separating out all the various helper templates like 
isUniformRNG, after which it should be much easier to avoid needing top-level 
module imports.