Just a dumb question, can you have two different types? UnfoldSequence and UnfoldStateSequence? Then they can have more focused generic parameters.
> On 26 May 2016, at 1:51 PM, Kevin Ballard via swift-evolution > <[email protected]> wrote: > > On Wed, May 25, 2016, at 08:49 PM, Chris Lattner wrote: >> >>> 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. > > And of course I spoke too soon, because T? isn't the right state to handle > this. It looks like I'll end up going with UnfoldSequence<T, (T?, Bool)>. > Slightly ugly, but most people won't be typing it that often, and we've had > worse (such as > LazyMapSequence<LazyFilterSequence<LazyMapSequence<Self.Elements, > ElementOfResult?>>, ElementOfResult>, which is quite a mouthful). > >> 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. > > Glad to hear it. > > -Kevin Ballard > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
