Comment #0 by bearophile_hugs — 2010-05-09T05:33:14Z
Designing good APIs is not easy. A collection of functions like std.string of Phobos must be large enough to allow all kind of handy operations on strings, but if it's too much large it gets harder to remember the functions and their purpose, and to use them the manual can be required, or it takes more time to remember the right function to use. So there is an optimal number of functions.
And the string functions must be well distinct from each other both in their purpose and in their name, so there is no risk of ambiguity about what function to use to solve a string problem while you program quickly.
This is true in general even for normal variable names, too much similar variable names are a bad programming practice because they can be confused by programmers that will read you code later.
In std.string there are two functions that are subtly different both in name and semantics, chomp and chop.
I propose to remove the 'chop' function, that is less useful: if the programmer wants to remove the trailing newline (a newline coming from readln()) the right function to use is chomp. This is a common need.
If the programmer wants to remove a fixed amount of chars from the end she/he can use a length test plus string slicing (the test is necessary because D slices are unsafe, unlike Python ones).
Comment #1 by nfxjfg — 2010-05-09T08:41:30Z
As far as I know, all of std.string is going to be deprecated in favour of ranges (std.range, std.algorithm).
Comment #2 by bearophile_hugs — 2010-05-09T09:22:47Z
std.string.chomp removes an optionally present trailing newline (that can be different on different operating systems, one or two chars, there are three variants of it). I will keep needing chomp functionality in future, and this is not a job fit for generic ranges/algorithms. So you are wrong.
I think Andrei agrees with me that Phobos2 can keep a std.string that contains things designed to be fit for strings. Some of such things can be just light wrappers around algorithms and ranges, but some of them are specific for strings.
An API for some handy string functions will be necessary still. And such API will be probably similar to the current one. So this bug report is valid still, because I think std.string.chop is not good and can be removed.
Comment #3 by dmitry.olsh — 2016-03-22T12:55:53Z
5 years later I think it makes sense to just deprecate chop.
Comment #4 by andrei — 2016-03-22T17:38:31Z
chop and chomp are borrowed from Perl. If I'd do it over again, probably I wouldn't add chop. At the same time, it's not terribly bad to have it there, so deprecating it (and breaking code that occasionally uses it) seems unnecessary. I'll close this, please reopen if I'm missing somtehing.