Comment #0 by bearophile_hugs — 2011-11-25T16:34:03Z
For uniformity with the other string functions I think std.string.countchars, std.string.removechars need a capital letter in the middle:
import std.string: countChars, removeChars;
void main() {
string s = "hello";
assert(s.countChars("l") == 2);
assert(s.removeChars("l") == "heo");
}
Comment #1 by issues.dlang — 2011-11-27T20:18:18Z
None of the functions in std.string which take a pattern are currently camelcased, because they weren't created that way initially. They haven't been changed, because there was some discussion about replacing them with versions which take RegEx instead of a pattern. If that's done, then the new functions would be properly camelcased, and the current ones would be deprecated. But I didn't want to go and rename those functions only to have to deprecate them later. The question is whether we do in fact want to change them to use RegEx, and if so, who's going to do that work. If not, we can look at renaming them.
Comment #2 by lt.infiltrator — 2014-03-19T22:04:06Z
Seeing as how they do not appear to have been replaced yet, should we think about renaming them to camel case now?
Comment #3 by issues.dlang — 2014-03-19T23:58:23Z
> Seeing as how they do not appear to have been replaced yet, should we think
about renaming them to camel case now?
No. We're not doing that anymore. At this point, we're stuck with whatever names we have. We've come too far along for breakage based on naming only. Walter and Andrei are both adamant about that at this stage (whereas previously, only Walter was against fixing names). The breakage just isn't worth the gain at this point given D's growth.
We really should replace the pattern functions in std.string with functions that take regex - and those function should be properly camelCased - but we're not going to rename anything at this point. It's far too late for that.
Comment #4 by bearophile_hugs — 2014-03-20T03:56:17Z
(In reply to comment #3)
> No. We're not doing that anymore. At this point, we're stuck with whatever
> names we have. We've come too far along for breakage based on naming only.
> Walter and Andrei are both adamant about that at this stage (whereas
> previously, only Walter was against fixing names). The breakage just isn't
> worth the gain at this point given D's growth.
We can still introduce countChars and removeChars aliases. And later deprecate the others.
Comment #5 by issues.dlang — 2014-03-20T16:18:45Z
> We can still introduce countChars and removeChars aliases. And later deprecate
the others.
That would still be renaming them. Maybe we could add new aliases, but we can't remove the old ones, so we'd end up with two names, which we generally try and avoid.
But even if the names were perfectly fine, we should be using regex rather than the ad-hoc patterns that are currently being used. And maybe if we added those, we could consider deprecating the old ones - but not simply for renaming purposes.