* [stdlib] String : RangeReplaceableCollection & BidirectionalCollection
* Add source compatibility hack for Swift.max
* Add source compatibility hack for Swift.min
* Remove redundant conformance in benchmarks
* Fix stupid typo I thought I'd already pushed
* XFAIL testing now-redundant conformance
* XFAIL an IDE test for now
By removing the _fastPath inside of grapheme breaking, we avoid
cooling off all the other blocks in the function, restoring
performance parity with before the ASCII special case logic. This does
not meaningfully impact the performance of the special case, so we are
still about 2-3x faster iterating forwards and backwards over ASCII
characters than before.
By doing a fast check for CR-LF, we can speed up forwards and
backwards character iteration on ASCII strings by ~2-3x. This speedup
can be seen in the stringTests suite (previous PR).
It is done as a fast path inside of
_measureExtendedGraphemeClusterForward/Backward, which is never
inlined. Doing the fast path inline would yield even more dramatic
improvements, and might be an area for future exploration, but would
slightly pessimize non-ASCII strings due to code bloat. Additionally,
the current implementation has not been micro-optimized yet. It's
possible that more optimal code would be smaller and have less of an
impact on the general case.
Eliminate the vestigial type `LazyFilterIndex`, which was
necessary pre-Swift-3 to allow the index to move. Swift 3's indexing
model means that the movement of indices is on the collection itself,
so we no longer need `LazyFilterIndex`: instead, the `Index` type of
the lazy filtered collection is simply the `Index` type of the base
collection, which is a nice convenience: it means you can take indices
from a lazy wrapper around a given collection C and use them with the
collection C (and, with care, vice-versa) without jumping through
extra hoops.
Part of ABI FIXME #99, this gives us some nice consistency that
ensures that slicing a SubSequence gives us another SubSequence. There
are two source-compatibility implications to this change:
* Collections now need to satisfy this property, which could not be
expressed in Swift 3. There might be some Collections that don't
satisfy this property, and will break with the Swift 4 compiler
*even in Swift 3 compatibility mode*. Case in point...
* The Lazy collection types were formulated as a lazy collection of
the base slice (e.g., LazyCollection<ArraySlice<T>>) rather than as
a slice of the lazy collection (e.g.,
Slice<LazyCollection<Array<T>>). The former doesn't meet the new
requirements, so change to the latter.
There isn't any work related to SE-0142 associated type where clauses
for these particular ABI FIXMEs. Rather, we get all of the constraints
we need from Collection and the recursive constraint we cannot yet
express, all of which are covered by other ABI FIXMEs.
Address ABI FIXME #68 by using same-type constraints directly on an
associated type to describe the requirements on the Indices associated
type of the Collection protocol. ABI FIXMEs #89, #90, #91 are all in
StdlibUnittest, and provoke warnings once #68 is fixed, but it's nice
to clear them out.
Fixes SR-2121.
