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
