Faster Command Line Tools in D

[Jonathan M Davis via Digitalmars-d-announce]

On Thursday, May 25, 2017 14:17:27 Suliman 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.
>
> Is there any plan to deprecate all splitters and make one single.
> Because now as I understand we have 4 functions that make same
> task.

I wouldn't expect any of the split-related functions to be going away. We
often have a function that operates on arrays or strings and another which
operates on more general ranges. It may mainly be for historical reasons,
but removing the array-based functions would break existing code, and we'd
get a whole other set of complaints about folks not understanding that you
need to slap array() on the end of a call to splitter to get the split that
they were looking for (especially if they're coming from another language
and don't understand ranges yet). And ultimately, the array-based functions
continue to serve as a way to have simpler code when you don't care about
(or you actually need) the additional memory allocations.

Also, splitLines/lineSplitter can't actually be written in terms of
split/splitter, because split/splitter does not have a way to provide
multiple delimeters (let alone multiple delimeters where one includes the
other, which is what you get with "\n" and "\r\n"). So, that distinction
isn't going away. It's also a common enough operation that having a function
for it rather than having to pass all of the delimeters to a more general
function is arguably worth it, just like having the overload of
split/splitter which takes no delimiter and then splits on whitespace is
arguably worth it over having a more general function where you have to feed
it every variation of whitespace.

- Jonathan M Davis