+1.  Stream support is long overdue.

~Robert Widmann

2015/12/28 2:20、Kevin Ballard via swift-evolution <[email protected]> 
のメッセージ:

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

Reply via email to