Faster Command Line Tools in D

[cym13 via Digitalmars-d-announce]

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