Expose IndexingIterator's initializer

Karl · 2021-04-20T18:44:14.050Z

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.

github.com

apple/swift/blob/4255a670c43a1350c663786953e8f509d5718a96/stdlib/public/core/Collection.swift#L88


      
            public /// @testable
            init(_elements: Elements) {
              self._elements = _elements
              self._position = _elements.startIndex
            }
          
          
  @inlinable
            @inline(__always)
            /// Creates an iterator over the given collection.
            public /// @testable
            init(_elements: Elements, _position: Elements.Index) {
              self._elements = _elements
              self._position = _position
            }
          }
          
          
extension IndexingIterator: IteratorProtocol, Sequence {
            public typealias Element = Elements.Element
            public typealias Iterator = IndexingIterator<Elements>
            public typealias SubSequence = AnySequence<Element>

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>.

xwu · 2021-04-20T20:20:32.354Z

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 IndexingIterator at 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.

Karl:

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> .

Why’s the concrete iterator type a problem?

Karl · 2021-04-20T20:35:29.526Z

xwu:

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.

Hm? Not sure what you mean here.

xwu:

Why’s the concrete iterator type a problem?

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.

xwu · 2021-04-20T22:43:16.440Z

Karl:

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 IndexingIterator at all, unless I’m missing something. Can you describe the use case you have in mind?

xwu · 2021-04-20T22:53:57.864Z

Karl:

xwu:

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.

Hm? Not sure what you mean here.

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().