On Sunday, 23 December 2012 at 16:06:57 UTC, John Colvin wrote:
On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei
Alexandrescu wrote:
I like std.algorithm the way it is.
Andrei
Same here. In my mind it's about generality:
General purpose algorithms (sort, partition etc.) belong in
std.algorithm and more specific algorithms belong in their own
appropriately named modules.
Levenshtein distance is general purpose?
I'm not too fussed about std.algorithm, but I think it could be
better. Here's some criticisms I have:
1. The iteration algorithms should be std.range. I find it
confusing that (for example) joiner and chain are in different
modules when they are so similar.
2. The set algorithms should be in their own module. They are
rarely used and quite specific in what they do.
3. The sorting algorithms should be in their own module. There
are many different sorting algorithms that could be added, and if
they stay in std.algorithm then it is going to get quite bloated.
Interestingly, EASTL also decided to split C++'s <algorithm> into
sorting, set, and heap components. I think this is the right
thing to do.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
My main worry is that std.algorithm becomes std.miscellaneous --
a place where things go when you can't think where else to put
them. The reason this happens is because of the name. As someone
mentioned earlier, just about every function implements an
"algorithm" of some sort, so people can feel justified in putting
everything in std.algorithm. Heck, if "min" is an "algorithm"
then anything is!
Would it be possible to split the library up and add public
imports to std.algorithm of the moved symbols?
