Personally I’d say this should be a -1 for standard-library inclusion. Swift’s not really built to handle infinite sequences right now; until they are handed better by the standard library convenience methods for creating them shouldn’t be in the standard library.
You’d also want to call `fatalError` for at least `reduce`, `reverse`, `sort`, `split`(?), `flatMap`, `dropLast`, `suffix`, and `forEach`. `startsWith` and `elementsEqual` and `lexicographicComparison` are all broken if you call them like e.g. `self.startsWith(self)`. You can conceivably implement a non-crashing `contains`, `minElement` and `maxElement` on `CycleSequence` by calling through to the wrapped collection, but that’ll seemingly evaporate as soon as your `CycleSequence` winds up hidden inside an `AnySequence`. Which illustrates why this is a -1 for me; there's nothing wrong with the functionality in isolation and there’s nothing wrong with infinite sequences, but the standard library should play well with itself, and this wouldn’t play well with the rest of the standard library. That opinion could change as the language changes or the standard library evolves. > On Dec 28, 2015, at 1:20 AM, Kevin Ballard via swift-evolution > <[email protected]> wrote: > > ## Introduction > > Add a new property `cycle` to CollectionType that returns an infinite > SequenceType that yields the elements of the collection in a loop. > > ## Motivation > > It's sometimes useful to be able to have an infinite sequence. For example, > `CollectionOfOne(x).cycle` could be used to have an infinite sequence of a > single element (similar to Repeat but without a count). A common use for > infinite sequences is zipping with a finite sequence. As far as I'm aware, > the stdlib does not currently provide any way to create such an infinite > sequence. > > ## Proposed solution > > Extend CollectionType with a new property `cycle` that yields a type that > conforms to SequenceType. This sequence yields each element of the collection > in an infinite loop. > > ## Detailed design > > 2 new types would be added: > > struct CycleSequence<Base : CollectionType> : LazySequenceType { ... } > struct CycleGenerator<Base : CollectionType> : GeneratorType { ... } > > CollectionType would be extended with a property: > > extension CollectionType { > public var cycle: CycleSequence<Self> { get } > } > > This is an extension of CollectionType instead of SequenceType because it > requires a multi-pass sequence (and SequenceType does not provide that > guarantee). The returned type conforms to SequenceType instead of > CollectionType because there is no possible `endIndex` that satisfies the > requirement of being reachable from `startIndex` by zero or more applications > of `successor()`. > > Because the default eager versions of map and filter will execute forever on > an infinite sequence, CycleSequence conforms to LazySequenceType instead of > SequenceType in order to provide lazy versions of those functions. > Additionally, it will provide implementations of the eager versions that > simply trigger a fatalError(), as the alternative is an infinite loop that > consumes more and more memory. > > ## Impact on existing code > > None > > -Kevin Ballard > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
