The underlying type's ordering may not be appropriate for the wrapped
type (think an ordered list whose underlying type is NSString).
Frameworks can always add a Comparable conformance explicitly.
We squeak out of this being a source-breaking change by virtue of
never having released a working version of it. Rintaro fixed the
ambiguity problems back in f11b74176b, but that was after the last
rebranch for Swift 3.1.
rdar://problem/30166538
Now that `String` conforms to the `BidirectionalCollection` protocol, in
the expression `let x = [""].joined()` the best matching overload for
`joined` is no longer the one returning `String`.
Fixes: <rdar://problem/31899440>
This eliminates the counting step for a lazy filtered collection
when converting it into an array by treating the collection
as a sequence when copying elements. FlattenCollections already
have this behavior. (SR-4164)
The box types were previously fileprivate because they lived in
the Foundation overlay. As part of the Swift stdlib, though, they need
to be internal so they can be linked against.
* 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.
