What's the point of having all these powerful, generic, abstract functions if we're just going to copy and paste code? :-)
This change has several benefits:
* It is far more elegant.
* Changes (optimisations) to startsWith automatically carry across to endsWith.
* We get extra testing for startsWith and retro for free.
Previously endsWith constraints only required input ranges, but the algorithm uses `back` and `popBack` within, so clearly a bidirectional range is needed.
This reverts commit 07104b5fe6.
As we cannot currenly rely on even ranges with slicing implementing
opDollar, this change breaks code, because it assumes that such ranges
implement opDollar.
- I assume they are not properties, then changed to normal functions.
- Global .moveFront/Back uses front and back if member moveFront/back doesn't exist.
Then, member aliases are just redundant.
find should work with multiple needles which are a combination of
elements and ranges rather than just all ranges - just like startsWith
and endsWith do - and since that overload of find calls startsWith, it's
trivial to make it take the same types of arguments as startsWith.
Changes:
1. Count:
1.1 Better conditional statement
1.2 Count will now turn down any infinite haystacks (or else you'd count to infinity...)
1.3 Infinite needle will instantaneously return a count of 0.
1.4 Fixes a condition that was checking pred(haystack, needle), as opposed to pred(haystack.front, needle.front) (guess no one ever tried a fuzzy count?)
1.5 Fixes reference range support...*
2. countUntil:
2.1 Better conditional statement
2.2 countUntil supports InputRange for element and predicate search.
2.3 Fixes unicode bug (return the amount of popFronts, not index)
2.4 Fixes http://d.puremagic.com/issues/show_bug.cgi?id=8804
2.5 Fixes http://d.puremagic.com/issues/show_bug.cgi?id=8821
Note: count is still subject to the bugs in splitAfter
* Incorrect reference range support
* Incorrect split for forward range
Both are corrected in another pull.
As such, no unittests are added (yet).
It makes little sense to join a range of infinite subranges, as we'll
never get beyond the first range, and besides, the outer range might be
empty so setting empty=false is wrong. OTOH, it's valid to have an
infinite range of subranges, in which case the output will be infinite.
So that should be the case that's checked for here.
splitter requires a sliceable range, contradicting
the ddoc. Additionally, one of the overloads
requires a sliceable range, but omits this from
the if-constraint.
This commit mentions the sliceable constraint in
the ddoc and tightens the constraints of the
overload to require slicing.
