What functions could be added to std.algorithm?

[Andrei Alexandrescu]

On 08/01/2010 09:32 AM, Philippe Sigaud wrote:
> On Sun, Aug 1, 2010 at 16:02, dsimcha <dsimcha at yahoo.com
> <mailto:dsimcha at yahoo.com>> wrote:
>
> [flat / nested]
>
>     Please, no.  This is why I hate Tango and Java.  It's too hard to
>     find what you
>     need, and you have to write too much import declaration boilerplate.
>
>
> I agree that Java pushed that too far for my taste also. Looking at
> Tango, it's indeed really nested. But hey, std.c.* is already two-levels
> and I never heard anyone complaining. I thought there was a kind of
> agreement about some modules in Phobos that were beginning to be quite
> big, but I may be wrong.
>
> Now that I think about it, my real problem on this point is not so much
> that std.algorithm is too big but that:
>
> - I don't always know whether such or such function in in std.string,
> std.algorithm, std.range, etc.
> - The doc pages are not particularly organized.
>
> I have to use Adam Ruppe's "find D keyword" website (very handy)
> regularly...
>
>       I love
>     Phobos's flat, simple, even if at times sloppy, import system.  Even
>     so, I have a
>     module in my personal lib that just publicly imports the 10 or so
>     Phobos modules I
>     use most frequently, because even in Phobos the amount of import
>     declaration
>     boilerplate is too much, but using std.all caused too many naming
>     collisions with
>     modules that I don't use.
>
>
> I do the same. I always end up importing the same 10-15 modules.
>
> But, what about putting all() and some() in std.algorithm?

I agree that all of the functions you suggested deserve a place in 
std.algorithm (or std.range). Please add one bugzilla entry or better 
yet let me know if you'd like to join Phobos's devs (subject to team 
approval) so you can add them yourself.

Also, I agree that std.algorithm has gotten a bit large. Any sensible 
ideas for addressing that should be discussed. Off the top of my head, 
I'm thinking that mutators vs. non-mutators could be a possible 
criterion for separation.

BTW, it warms my heart to see that our std.algorithm is the fourth 
Google hit when searching for std::algorithm (or std.algorithm, which 
seems to produce the same results). I feel std.container can be a 
similarly compelling offering. *cough*RBTree*cough*Steve*cough*


Andrei