Type-specific iterators should probably move inside, too, unless there's another plan for them. DictionaryIterator, StrideToIterator, Zip2Iterator, etc.

Good point. There isn't another plan for them – in fact we want to add more (to leave open the option of customizing them for performance later). Though several of these are subject to refactoring e.g. Zip2 might become a Collection when it's zipping collections once we have conditional conformance. So this should probably wait until after that to avoid conflicts.

@swift-ci create

Comment by Daniel Tull (JIRA)

I have made a commit that nests the StrideTo and StrideThrough iterators.

Tests fail in api-digester/stability-stdlib-abi.swift and api-digester/stability-stdlib-source.swift because the result of makeIterator() is different, which I suppose is to be expected. The commit also adds typealias to the current names, I imagine that to complete this work, those can be removed and tests updated for the new types.

Would this be the correct way forward? Please let me know what to do next to get this merged in.

You can see the diff of the change here: master...danielctull-forks:SR-3397.

Regarding the ones mentioned here:

• DictionaryIterator was nested here
• DictionaryIndex was nested here
• Zip2Iterator was nested here
• ClosedRangeIndex was nested here
• StrideToIterator and e.g. StrideThroughIterator are still top-level and there is little if anything we can do about that at this point.

It seems none of these changes went through evolution though, so I’m dropping the label.

@airspeedswift Why were DictionaryIterator, SetIterator, etc. not deprecated and moved to migration support like others?