On Thursday, May 25, 2017 08:46:17 Steven Schveighoffer via Digitalmars-d-
announce wrote:
> std.string, std.array, and std.algorithm all have cross-polination when
> it comes to array operations. It has to do with the history of when the
> modules were introduced.

Not only that, but over time, there has been a push to generalize functions.
So, something that might have originally gotten put in std.string (because
you'd normally think of it as a string function) got moved to std.array,
because it could easily be generalized to work on arrays in general and not
just string operations (I believe that split is an example of this). And
something which was in std.array or std.string might have been generalized
for ranges in general, in which case, we ended up with a new function in
std.algorithm (hence, we have splitter in std.algorithm but split in

The end result tends to make sense if you understand that functions that
only operate on strings go in std.string, functions that operate on dynamic
arrays in general (but not ranges) go in std.array, and functions which
could have gone in std.string or std.array except that they operate on
ranges in general go in std.algorithm. But if you don't understand that, it
tends to be quite confusing, and even if you do, it's often the case that
when you want to find a function to operate on a string, you're going to
need to look in std.string, std.array, and std.algorithm.

So, in part, it's an evolution thing, and in part, it's often just plain
hard to find stuff when you're focused on a specific use case, and the
library writer is focused on making the function that you need as general as

- Jonathan M Davis

Reply via email to