On Thursday, 25 May 2017 at 16:19:16 UTC, Jonathan M Davis wrote:
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.
I don't think know if people coming from other languages would
really mind. Of course it would have to be taught onces,
everything has, but many languages (and I have python especially
in mind) have been lazifying their standard libraries for years
now. I think consistency is what brings less questions, not
diversity where one of the possibilities corresponds to what the
programmer wants. He'll ask for the difference anyway.
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
