I had optimistically written the code here optimistically hoping #7837 would land in time for me to merge, but that didn't happen, so adjust some things to match the current 12-byte object header size on 32-bit, and introduce some ABI constants for the expected 32- and 64-bit object header sizes we can assert against so that we have some robustness when it eventually changes again. Implements rdar://problem/31768303.
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
