Make the Indices types conform to the appropriate Collection protocol:
* Collection.Indices: Collection
* BidirectionalCollection.Indices: BidirectionalCollection
* RandomAccessCollection.Indices: RandomAccessCollection
Introduce (recursive) constraints that make the *Collection constraint
of SubSequence match that of its enclosing *Collection, e.g.,
MutableCollection.SubSequence conforms to MutableCollection.
Fixes rdar://problem/20715031 and more of SR-3453.
* Unify the capitalization across all user-visible error messages (fatal errors, assertion failures, precondition failures) produced by the runtime, standard library and the compiler.
* Update some more tests to the new expectations.
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
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.
The BidirectionalCollection protocol has no requirements that mention
the associated type 'SubSequence', which means it cannot be easily
inferred. Duplicate the subscript requirement from Collection into
BidirectionalCollection to aid type witness inference.
It's important to let people know that, in contrast with existing
practice in other frameworks, we really are going to remove the
deprecated API, and soon.
This resolves the issue described in SR-1922, where conformance
to a bidirectional collection gives errors when implemented using
only the minimal protocol requirements.
This revises and expands on documentation for the new collection methods
for working with indices and the revised Swift 3 set APIs. In addition,
it includes documentation for the new range types.
The defaults we were generating for Collection and
BidirectionalCollection didn't make any sense, because if you could do
that strideable arithmetic then you essentially had random access.
Instead we constrain the defaults to apply to RandomAccessCollection
where the Indices are a CountableRange.
- Replaced RandomAccessIndex mentions from Strideable documentation
with stronger guarantees if Stride conforms to Integer.
- Other cleanup and revisions.
