For some reason, IndexingIterator's initializer, despite being public, contains underscores which prevent it from appearing in code-completion, and seem to suggest that it shouldn't be used.
I'd like to pitch removing those underscores. I can't think of a reason why we'd want to prevent users from creating an IndexingIterator starting at a particular Index.
It's essentially possible to do this already by creating an iterator over a slice, but doing so changes the iterator's type, making it an IndexingIterator<Slice<MyCollection>> rather than an IndexingIterator<MyCollection>.
These entry points are public only for standard library testing purposes.
As I understand it, there’s no intention to make it possible for the end user to initialize an IndexingIteratorat all. Instead, users obtain an instance by calling makeIterator() on a collection type that doesn’t override the default implementation. But there shouldn’t ever be a need to support mixing-and-matching the default iterator with a collection type that provides a custom iterator.
Why wouldn't it be a problem? MyCollection's iterator type is IndexingIterator<MyCollection>, not IndexingIterator<Slice<MyCollection>>, so it isn't able to return an offset iterator as an instance of its own iterator.
If this function isn't supported, it means that we require users to write their own iterators - even when the default would have been fine - just to support this obvious functionality. It isn't very difficult, but it is very annoying to have to reimplement basic types like this.
I’m not sure I understand. There is no publicly documented API to instantiate IndexingIteratorat all, unless I’m missing something. Can you describe the use case you have in mind?
Where a type defines its own custom iterator, it is not the intention of Swift to support the end user instantiating IndexingIterator(elements: valueOfMyCollectionTypeWithCustomIterator). They should always use valueOfMyCollectionTypeWithCustomIterator.makeIterator().