What functions could be added to std.algorithm?

Philippe Sigaud philippe.sigaud at gmail.com
Sun Aug 1 07:32:50 PDT 2010


On Sun, Aug 1, 2010 at 16:02, dsimcha <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?

Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100801/564ce7ea/attachment.html>


More information about the Digitalmars-d mailing list