Although it is a bit of a corner case, I would argue that the
following behaviour is buggy:
assert(findSplit!(reverseArgs!canFind)("078.12.13-4.5", ".-")
== tuple("078", ".1", "2.13-4.5"));
To understand why, consider the following more explicit code:
void main()
{
static bool oneOf(dchar a, string b)
{
bool r = false;
foreach(c; b)
{
if(c == a)
{
r = true;
break;
}
}
writefln(`matching a='%s' b="%s" returns %s`, a, b,
r);
return r;
}
auto s = findSplit!oneOf("078.12.13-4.5", ".-");
writefln("%s %s %s", s[0], s[1], s[2]);
}
Output:
matching a='0' b=".-" returns false
matching a='7' b=".-" returns false
matching a='8' b=".-" returns false
matching a='.' b=".-" returns true
078 .1 2.13-4.5
The findSplit documentation says: "result[1] is the portion of
haystack that matches needle". Yet, the only character for which
the predicate returned true was '.'. Therefore, that should be
the only part of result[1]. The alternative would be to clarify
and change the documentation, I guess.
BTW 1: it's not very clear what the predicate arguments are / can
be, unless I missed some part of the docs. Apparently, findSplit
tries to use both `bool function(dchar, dchar)` and `bool
function(dchar, string)`, IIRC.
BTW 2: Any particular reason for binaryReverseArgs to exist,
instead of always just using reverseArgs?
