phobos dependencies

[Simen Kjærås]

On 2013-12-19 10:56, Joseph Rushton Wakeling wrote:
> On 19/12/13 00:08, Walter Bright wrote:
>> 4. Break kitchen sink modules like std.algorithm into one module per
>> algorithm.
>> This should not result in code duplication.
>
> That might be desirable for other purposes anyway (std.algorithm is
> big!), but how does this differ from the existing possibility of doing,
> e.g.,
>
>      import std.algorithm : sort;

Your line of code imports all of std.algorithm, as well as all modules 
imported by std.algorithm, etc. This includes functions used by topN, 
largestPartialIntersectionWeighted, findSplit, and so on.

A modularized std.algorithm.sort would only import what sort needs (and 
what sort's needs need, and so on, but likely a much small graph).

"But why can't we make the compiler smrter, so import std.algorithm : 
sort; only imports what's needed?" you might ask. I believe it's already 
been covered in this thread: overloads, for one (knowledge of all 
overloads is required). Second, if an imported type is used, how should 
the compiler guess which module contains the type? There may be more 
reasons, too.

--
   Simen