> On May 25, 2016, at 8:39 PM, Kevin Ballard via swift-evolution > <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
