[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.

-Chris



More information about the swift-evolution mailing list