Re-add overload for fixed-size arrays to std.string.indexOf

[schuetzm]

Fixed the regression introduced in #3172

[schveiguy]

Hm.. I think this is not what was asked for. The original code did not instantiate a new template per static array size. This is kind of a very tricky issue, because you want to use T[] not T[N], but T[] is a valid range, so it will match the first overload also.

The only good news here is that the template bloat should be minimal in terms of code size (the function should always inline), but it will hurt in the symbol table. If ever there was a case for @forceinline, this is it.

I'm OK with this change, the template bloat should not be that bad. If others feel differently, I'd love to hear another solution.

[schuetzm]

I could factor the actual implementation out into a third, private template that is called by both of the others. But IMO it's not worth the trouble, and it would even make the common case worse, because it would instantiate two templates for each type.

[WalterBright]

use:

ref T[n] s

instead, otherwise the entire array gets copied to the stack!

[schveiguy]

Oh right, good catch!

[schveiguy]

But IMO it's not worth the trouble

yeah, agreed.

[schveiguy]

LGTM with latest changes.

[JakobOvrum]

You'd think that having an overload receiving T[] would work properly as it is more specialized than just Range, but DMD doesn't implement it...

[JinShil]

This pull request introduced a regression: https://issues.dlang.org/show_bug.cgi?id=14735

[schuetzm]

Can someone figure this out? Removing the overload added in this PR makes it work, but this overload shouldn't match for the test case in the bug report, so I don't see how it could even have an effect. Is this a compiler bug?

[JinShil]

The problem has something to do with the CaseSensitive argument. See the bug report for a test case.

[MartinNowak]

Was this the only regression regarding static arrays of newly rangified functions?

[MartinNowak]

An optimization would be to use const(T)[], b/c of less template instantiations.

[MartinNowak]

I think a better alternative would be to add explicit function overloads for const(char/wchar/dchar)[].
That makes sure the overload is more specialized, we can precompile the most common instantiations into libphobos, and it allows to coerce to const(char)[] to deduplicate all const variations of narrow strings.

void indexOf(Range)(Range s, in dchar c) @safe pure
{
    pragma(msg, "Range "~Range.stringof);
}

void indexOf(const(char)[] s, in dchar c) @safe pure
{
    pragma(msg, "const(char)[]");
    .indexOf!(const(char)[])(s, c);
}

unittest
{
    char[] ary;
    char[128] sary;
    indexOf(ary);
    indexOf(sary);
}

[MartinNowak]

This is troublesome b/c of polysemeous string literals and conversion of other arguments.

void test(const(char)[] s, in dchar c) {}
void test(const(dchar)[] s, in dchar c) {}

void test()
{
    test("foo", 'a'); // 2nd arguments matches with conversion, so both overloads match equally well
}