Bug 15285 – Range-ified functions for std.string

The following functions is std.string can be range-ified or can get range accepting equivalents: abbrev capitalize isNumeric inPattern munch representation soundexer soundex squeeze succ translate outdent wrap If capitalize has the same output as std.uni.toCapitalized, then it can just be alias-ed.

soundexer/soundex being on there is a mistake, sorry.

@JackStouffer - is there actually interest/use in allowing ranges for these functions? [1,2,3].abbrev doesn't make so much sense to me ...

Ideally, all of the string functions would at least accept ranges of characters, even if that's limited to random-access ranges. Otherwise, code that uses something like byCodeUnit is going to be in trouble, and arguably, byCodeUnit should generally be favored over using strings as ranges given the autodecoding issues. Whether the string functions accept non-character ranges is another matter entirely, and if we add functions like that, they really shouldn't be in std.string.

Hey I had a look at what types does functions allow: abbrev string[] capitalize isSomeString isNumeric isSomeString inPattern isSomeString munch isSomeString representation Char[] (char[],wchar[],dchar[]) squeeze anything - no constrains??? succ isSomeString translate immutable char[] outdent isSomeString wrap isSomeString I guess the biggest win is, if we first focus on those isSomeString functions. So you mean we could add to isSomeString a RangeString? ``` template isRangeString(R) { enum bool isRangeString = is(typeof( (inout int = 0) { static assert(isInputRange!R); static assert(hasLength!R); // all the algorithms allocate a new immutable string static asssert(isSomeChar!(isElementType!R)); } } ``` The only problem then would be that currently those algorithms use an index-based for-loop ``` for (size_t i = j; i < iLen; i++) { immutable c = s[i]; ``` can we just replace that with ``` foreach (i,immutable c;s) ``` so in summary - my questions: 1) can we replace for --> foreach or do we have to use `static if`? 2) we still will return a newly allocated immutable string. Should we return something different for ranges?

> So you mean we could add to isSomeString a RangeString? I mean something like if(isInputRange!Range && isSomeChar!(ElementEncodingType!Range) && !isConvertibleToString!Range) { } which is what some of the functions in std.string already have. In some cases, a bidirectional or random-acesss range might be required, but it's a range of char, wchar, or dchar that isn't an array. > 1) can we replace for --> foreach or do we have to use `static if`? That would depend entirely on the function. In many cases, you'd probably end up with a different overload. For instance, that's what indexOf did. Some of its overloads operate on strings, whereas others operate on aribtrary ranges of characters. > 2) we still will return a newly allocated immutable string. Should we return something different for ranges? That would depend on the function. If the function is supposed to return a newly allocated string, then that's probably what it's going to need to do, but in some cases, it may be able to return the original range (or a slice of it), and most functions that return a newly allocated array should eventually have a counterpart that returns another range type so that it can avoid allocations. But essentially, what we want is for the functions in std.string to operate on arbitrary ranges of characters in a way that's compatible with the current API. Generic code will need to work the same way with these functions whether they're taking strings or ranges. But exactly what needs to happen is going to depend on the function in question, and we'll have to look at that on a case by case basis.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/phobos/issues/10146 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB