Bug 1858 – std.string find signature is not string

In std.string, the find and ifind routines use char[] rather than string in their parameter signatures. This seems odd because these functions do not modify the parameter data and most other 'string' functions use string instead of char[]. As most other routines use string I find that I have to make exceptions for these ones in my code. As a workaround, I need to include the functions below in my code... int find(string a, string b) { return std.string.find(a.dup, b.dup); } int ifind(string a, string b) { return std.string.ifind(a.dup, b.dup); } Which involves useless copying.

The signatures I'm seeing in the current release's codebase (2.0) are all using "in char[]", which is equivalent to "scope const char[]", which accepts mutable, const, and invariant arrays. Could you show a code sample that has a problem? FWIW, this compiles and runs fine on my system: import std.string; void main() { string a = "abc", b = "bc"; assert(find(a, b) == 1); } Andrei

Here is the type of code that was giving me trouble. import std.string; int function(string a, string b) Finder; void main() { Finder = &std.string.find; } I am assuming the compiler is smart enough to work out which 'find' function I'm after by using the signature provided by the 'Finder' declaration.

The example code below works just how I expected the compiler to work. It displays '10', so I know it found the right 'xfind' function. import std.stdio; int function(string, string) lFind; void main() { lFind = &xfind; writefln("%s", lFind("abc", "def")); } int xfind(string x, string y) { return 10; } int xfind(ubyte[] x, ubyte y) { return 20; } int xfind(char *x, double y) { return 30; }

Oh I see. This is best solved in the language - a function type F1 should be implicitly convertible to another function type F2 if all of F1's parameters are subtypes of the corresponding parameters in F2. Arrays of const are a subtype of arrays of invariant (and actually this is another feature that is needed in a number of places), which takes care of the case in point. So I hereby assign this to Walter. :o)

Marked as enhancement request.