Splitting std.algorithm

[Jonathan M Davis via Digitalmars-d]

On Tuesday, January 20, 2015 18:02:47 H. S. Teoh via Digitalmars-d wrote:
> On Tue, Jan 20, 2015 at 05:26:41PM -0800, Jonathan M Davis via Digitalmars-d wrote:
> > and in my experience, large modules like std.algorithm or std.datetime
> > are actually quite maintainable.  However, that doesn't mean that we
> > wouldn't be better off splitting up the particularly large ones. I
> > just started on splitting std.datetime again the other day, and
> > hopefully I can find time enough to finish it before I end up having
> > to deal with merging other changes in.
>
> std.datetime is one of those things that has grown large enough that
> it's causing a noticeable pause when I open it in my editor or search
> for a symbol... I think that's nearing the point where splitting just on
> basis of size may become justifiable. :-P
>
> (Having said that, though, std.datetime unittests actually compile and
> run on my machine, in spite of their far larger number, yet
> std.algorithm doesn't. I think it's because of too many deeply-nested
> templates in std.algorithm, which probably includes a problem of my own
> making, namely one of the overloads of cartesianProduct, that causes an
> exponential number of recursive template instantiations. I've been
> meaning to fix that, and have in fact managed to fix it for the finite
> range case, but the infinite range case thus far eludes me.)

Oh. I think that std.datetime is large enough that it would be better to
split it up. It was actually split when I originally proposed it. It was
just split so badly that I was told to put it back together again (and it
improved quite a bit over the course of the review process). It's large
enough that github won't display the whole thing, and it's far larger than
any other module in Phobos. So, there are definitely good reasons to split
it up. But as far as maintaining it goes, I haven't found it to be a problem
at all that it's in a single file.

- Jonathan M Davis