[swift-evolution] [Pitch] New collection-based 'repeat' API

[Xiaodi Wu]

So, having played with this for a bit, it's not clear to me that a more
elaborate implementation of `cycle` functionality would be measurably
beneficial over a barebones one.

Documentation for `Sequence` clearly indicates that `dropLast` and `suffix`
must not be used on infinite sequences. The same can be said to be obvious
for `map`, `split`, and the current incarnation of `filter` because these
functions return arrays. All other protocol requirements except
`drop(while:)` behave as expected with their default implementation.

There is an improvement possible for `drop(while:)` in that it can be made
to return instead of looping forever if the predicate matches every value.
However, numerous protocol extension methods that can be shadowed but not
overridden have the same issue, and the true solution to that problem is
not within the scope of an additive change (it'd require re-designing
`Sequence` itself--for overall questionable gain, I think).

With that in mind, I'd suggest that we're not looking at much more than
this:

```

extension Collection {

  public func cycled() -> Cycle<Self> {

    return Cycle(self)

  }

}


public struct Cycle<T : Collection> {

  public let repeatedValues: T

  internal var _iterator: T.Iterator


  internal init(_ _repeatedValues: T) {

    self.repeatedValues = _repeatedValues

    self._iterator = _repeatedValues.makeIterator()

  }

}


extension Cycle : IteratorProtocol, Sequence {

  public var underestimatedCount: Int {

    return repeatedValues.count > 0 ? Int.max : 0

  }


  public mutating func next() -> T.Iterator.Element? {

    if let next = _iterator.next() { return next }

    _iterator = repeatedValues.makeIterator()

    return _iterator.next()

  }

}
```


On Tue, May 2, 2017 at 12:45 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> Very useful links. Clearly, `cycle` is a related topic. It's at once more
> general, in that it would operate on sequences and produce an infinite
> sequence, and much more tricky to implement, as evidenced by the extensive
> discussion on support for cycling infinite sequences. Both of those factors
> could arguably change the balance in terms of thresholds for inclusion in
> the standard library.
> On Tue, May 2, 2017 at 11:40 Ole Begemann via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> On 02.05.2017 18:33, Ole Begemann via swift-evolution wrote:
>>
>> For reference, here are some links to previous discussions on related
>> topics:
>>
>> 1) Kevin Ballard in December 2015: Proposal: CollectionType.cycle
>> property for an infinite sequence
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004635.html>
>>
>> 2) Ben Cohen in February 2016: Sequence/Collection Enhancements
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032120.html>
>> (one of the enhancements that Ben proposed to consider for adding to the
>> standard library is a cycle method for Collection and/or Sequence. I
>> don't think there is a more specific proposal for this yet, but at least we
>> know it's on the core team's radar.
>>
>> This should be *February 2017*, of course. Sorry.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170502/1e431b14/attachment.html>