* One-sided ranges and RangeExpression
* Remove redundant ClosedRange methods from String
* Fix up brittle tests
* Account for Substring update
* XFAIL range diagnostics on Linux
You shouldn't need to be Codable in order to get these implementations;
being either Encodable or Decodable should be enough to get the relevant
default implementation
Reverse iteration over a collection is significantly slower than forward.
REVERSE_COLLECTION
user 0m4.609s
user 0m4.587s
user 0m4.585s
COLLECTION
user 0m3.423s
user 0m3.517s
user 0m3.492s
A variety of enhancements from SE-154 and SE-165:
- Custom Keys and Values collections for Dictionary
- Two sequence-based Dictionary initializers
- Merging methods for Dictionary
- Capacity checking and reserving for Dictionary and Set
- Type-specific filter(_:) methods for Dictionary and Set
- A mapValues(_:) method for Dictionary
- A grouping Dictionary initializer
Many of StringCore private APIs, when the StringCore is itself a
substring, expect relative offsets rather than absolute offsets. This
fixes a bug in the sub-0x300 fast path where we were using absolute
offsets. Test cases added.
Adds in a special case grapheme break detection between two values
within scalar ranges where we have special knowledge. Any sub-0x300
scalars, except CR-LF, are guaranteed to have grapheme breaks between
them. We're reasonably confident this will not change in future
versions of Unicode. We might add more ranges in the future, but
should do so conservatively, anticipating future Unicode changes.
In these cases we can very quickly break, even for strings that have
mixed latin and emoji characters. In a ASCII string with a single
emoji in it, we traverse the string 2x faster forwards and 3x faster
in reverse. (Reverse is 3x faster as it involves some forwards
traversal inside of the index). For a string that's half Latin half
non-Latin, we're about 1.5x faster forwards and backwards.
* [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.
