[swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

Chris Lattner clattner at apple.com
Wed May 25 22:49:33 CDT 2016

> On May 25, 2016, at 8:39 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> On Thu, May 19, 2016, at 05:52 PM, Kevin Ballard wrote (on a different thread):
>> 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. 
> For the record, I just realized that the type signature of UnfoldSequence<T> actually requires that we do heap allocation as well, because this type can only be used for the stateful version if we erase the state type by capturing it in a closure.
> As part of implementing this, I'm going to go ahead and modify the type signature to UnfoldSequence<T, State>, with `state(first:next:)` returning the type UnfoldSequence<T, T?>. I think it's better to diverge slightly from the proposal than it is to introduce unnecessary (albeit small) performance cost. I hope there are no objections.

That makes sense to me - the core team review discussion did not specifically discuss the return type in question, nor its naming.  In my opinion, these implementation concerns can be handled by patch review process.


More information about the swift-evolution mailing list