https://issues.dlang.org/show_bug.cgi?id=15285

--- Comment #1 from Jack Stouffer <jack@jackstouffer.com> ---
soundexer/soundex being on there is a mistake, sorry.

--

https://issues.dlang.org/show_bug.cgi?id=15285

greenify <greeenify@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |greeenify@gmail.com

--- Comment #2 from greenify <greeenify@gmail.com> ---
@JackStouffer - is there actually interest/use in allowing ranges for these
functions?
[1,2,3].abbrev doesn't make so much sense to me ...

--

https://issues.dlang.org/show_bug.cgi?id=15285

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang@jmdavisProg.co
                   |                            |m

--- Comment #3 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=15285

--- Comment #4 from greenify <greeenify@gmail.com> ---
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?

--

https://issues.dlang.org/show_bug.cgi?id=15285

--- Comment #5 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
> 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.

--

https://issues.dlang.org/show_bug.cgi?id=15285

Seb <greensunny12@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |bootcamp
                 CC|                            |greensunny12@gmail.com

--

https://issues.dlang.org/show_bug.cgi?id=15285

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=15285

--- Comment #6 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
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

--