* Make Range conditionally a Collection
* Convert ClosedRange to conditionally a collection
* De-gyb Range/ClosedRange, refactoring some methods.
* Remove use of Countable{Closed}Range from stdlib
* Remove Countable use from Foundation
* Fix test errors and warnings resulting from Range/CountableRange collapse
* fix prespecialize test for new mangling
* Update CoreAudio use of CountableRange
* Update SwiftSyntax use of CountableRange
* Restore ClosedRange.Index: Hashable conformance
* Move fixed typechecker slowness test for array-of-ranges from slow to fast, yay
* Apply Doug's patch to loosen test to just check for error
Use the new `_Default_Foo` typealias trickery to define a conditional
default type witness for the collection `Indices` associated type, so
`Indices` becomes `CountableRange<Index>` when the `Index` type is
`Strideable` with `Int` as its `Stride` type.
This fixes the major regression with associated type inference for
“minimal” random access collection types with `Int` index types, which
has come up in a number of places.
Note that I dropped the `@_implements` requirement because `_Default_Foo`
is already off in its own namespace, and eventually we should get a real
syntax for this.
Fixes rdar://problem/35035322.
* Eradicate IndexDistance associated type, replacing with Int everywhere
* Consistently use Int for ExistentialCollection’s IndexDistance type.
* Fix test for IndexDistance removal
* Remove a handful of no-longer-needed explicit types
* Add compatibility shims for non-Int index distances
* Test compatibility shim
* Move IndexDistance typealias into the Collection protocol
* Refactor Indices and Slice to use conditional conformance
* Replace ReversedRandomAccessCollection with a conditional extension
* Refactor some types into struct+extensions
* Revise Slice documentation
* Fix test cases for adoption of conditional conformances.
* [RangeReplaceableCollection] Eliminate unnecessary slicing subscript operator.
* Add -enable-experimental-conditional-conformances to test.
* Gruesome workaround for crasher in MutableSlice tests
The various _*Indexable protocols only exist to work around the lack of
recursive protocol constraints. Eliminate all of the *_Indexable protocols,
collapsing their requirements into the corresponding Collection protocol
(e.g., _MutableIndexable —> Collection).
This introduces a number of extraneous requirements into the various
Collection protocols to work around bugs in associated type
inference. Specifically, to work around the lack of "global" inference
of associated type witnesses. These hacks were implicitly present in
the *Indexable protocols; I've made marked them as ABI FIXMEs here so
we can remove them when associated type inference improves.
Fixes rdar://problem/21935030 and a number of ABI FIXMEs in the library.
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.
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 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.
... as well as new test collection types:
`MinimalRandomAccessCollectionWithStrideableIndex` and
`DefaultedRandonAccessCollectionWithStrideableIndex`, to test default
implementation of `index(...)` family of functions provided by the
standard library for the random access collections with strideable
indices.
precondition(), when used in the standard library, does not respect the
debug/release build setting of the module or application importing the
standard library.
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.
Making constraining the indices of RandomAccessCollections to be
Strideable has dubious semantic implications and makes implementing
AnyRandomAccessCollection really hard.
This adds a basic aspect of the new indexing model on top of the
existing Collection code in a passive way. Things should continue to
function as before.
