std.algorithm (Was: dlang.org Library Reference)

[Peter Alexander]

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?