Once you start using it, it's really hard to put it down. -- E, who will not make the obvious "for" joke
> On May 19, 2016, at 7:10 PM, Patrick Smith <[email protected]> wrote: > > I think that is a little confusing and has potential to be ‘abused’. I think > it’s more confusing that a `for(;;)` loop for instance, and that got removed. > I think var + AnyIterator is more explicit, and can become the canonical way > to do this. > > Hopefully AnyIterator can be optimized to the same performance. > > >> On 20 May 2016, at 10:57 AM, Erica Sadun via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On May 19, 2016, at 6:52 PM, Kevin Ballard via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> After having given this some thought, it seems apparent that >>> `sequence(state:next:)` is equivalent to `AnyIterator({ ... })` where the >>> closure captures a single mutable variable. The microbenchmark performance >>> may differ slightly, as the AnyIterator version will allocate a box on the >>> heap to hold the captured variable (assuming it can't get inlined >>> entirely), whereas UnfoldSequence won't. But the functionality is the same. >>> >>> Thus the question: do we want to keep `sequence(state:next:)` or is it too >>> close to AnyIterator in functionality? Arguments in favor of >>> `sequence(state:next:)`: >>> >>> * It's equivalent to unfold and the dual of reduce, so people who've used >>> functional programming languages may expect it to exist. >>> * It allows you to create ad-hoc stateful sequences without polluting the >>> current scope with a variable that exists solely to be captured. >>> * If the cost of a small heap allocation is significant for your code, it >>> may be more performant than AnyIterator. >>> >>> Personally, the most important reason here for me is not having to pollute >>> the current closure with a variable. And this could actually be solved >>> another way, by allowing the use of `var` in a capture list, which would >>> let you say something like `AnyGenerator({ [var state=foo] in ... })`. >>> >>> Given all this, at this point I'm actually leaning towards >>> saying`sequence(state:next:)` doesn't pull its own weight and we should >>> just go with `sequence(initial:next:)`. >>> >>> -Kevin Ballard >> >> Adding on, to the best of my understanding the biggest win in the stateful >> variation is to be able to create a sequence from a starting state without >> declaring any external variables, as in the perfectly wrong and evil example >> I showed Kevin: >> >> enum Finger: Int { case Thumb = 1, Pointer, Middle, Ring, Pinky } >> >> extension Finger { >> static func members() -> AnySequence<Finger> { >> return sequence(Thumb.rawValue, next: { >> (inout idx: Int) in >> defer { idx += 1 } >> return Finger(rawValue: idx) >> }) >> } >> } >> >> for finger in Finger.members() { print(finger) } >> >> -- E >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
