Concurrently with the development of struct IndexSet, the stdlib team
was busy reworking the way that all indexes in collections worked
(https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md).
Both efforts landed at basically the same time. We did the minimum
possible to adopt the new indexing model when IndexSet landed. This
change more correctly adopts the new model.
In summary, the new model has the Collection change the value of the
Index, instead of the Index changing the value on its own. Previously,
the Index had methods like successor(), but now the Collection has
methods like index(after:). This means that the index no longer has to
store a reference to the collection in many cases, which means that CoW
semantics can kick in far more often as the index is a dead simple model
object that just stores a bunch of integers. So basically, this change
moves all the logic for moving indexes from Index into IndexSet.
<rdar://problem/26269319> More fully adopt new indexing model for better performance in IndexSet
The Swift 3 refactoring of the range type has led to its split into 4
different types. The IndexSet API should accept any of these as long as
they contain the element type (Int, which is inherently Countable). This
allows callers to use both the ... and ..< syntax, for example.
This commit also adds additional unit tests for some of the IndexSet
API, and turns a few methods with optional/default args into properties
or a method family, since otherwise callers would end up with an
ambigious method call as the range argument would have been defaulted to
nil.
<rdar://problem/26532614> Add overloads for range types to IndexSet
