I do like `sequence`, though I'm not sold on the name AdHocSequence
(just from that name it's hard to figure out what it does). An
alternative is `expand`, which is nice because it pairs with `reduce`,
but it's less obvious that it produces a sequence and the name isn't as
good with the stateful version.
As for return type name, we could go ahead and use UnfoldSequence<T>
anyway even though the function isn't named `unfold`, because this name
will make sense to people who do know what unfold is, and I'm not
convinced we can have a meaningful name for people who don't (since
SequenceSequence is too silly).
So given that, I'll suggest the following:
func sequence<T>(initial: T, next: T -> T?) -> UnfoldSequence<T>
func sequence<T, State>(state: State, next: (inout State) -> T?) ->
UnfoldSequence<T>
I'm suggesting `sequence(initial:next:)` instead of the previously-
suggested `sequence(from:applying:)` because the term "from" could
equally well mean the first element or the state, whereas "initial"
should make it more obvious that this value is the first element of the
resulting sequence. And I'm using "next" as suggested by Erica because
the function does return the next element, and it's similar to the
IteratorProtocol method. I've also chosen to change the stateful version
to use an inout parameter, as previously suggested, because it's
equivalent to the State -> (T, State)? in functionality but is less
likely to produce unwanted COW copies.
-Kevin Ballard
···
On Fri, May 13, 2016, at 11:08 AM, Erica Sadun wrote:
On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution <swift- > evolution@swift.org> wrote:
The proposal has been updated as per feedback from the core team
(https://github.com/apple/swift-evolution/pull/275\). This includes
removing some last vestiges of Swift 2 naming as well as replacing
`iterate(_:apply:)` with an overloaded function
`unfold(_:applying:)`.The proposal says this:
public func unfold<T, State>(_ initialState: State, applying: State
-> (T, State)?) -> UnfoldSequence<T>
public func unfold<T>(_ initialElement: T, apply: T -> T) ->
UnfoldSequence<T>However, the comment implies that the second one should instead
be this:public func unfold<T>(_ initialElement: T, applying: T -> T?) ->
UnfoldSequence<T>I'm not sure I like having these be overloaded on only the return
type of the closure. Maybe we could do something like this?public func unfold<T, State>(fromState initialState: State,
applying: State -> (T, State)?) -> UnfoldSequence<T>
public func unfold<T>(fromFirst initialElement: T, apply: T -> T) ->
UnfoldSequence<T>That way you're calling either `unfold(fromState:applying:)` or
`unfold(fromFirst:applying:)`. (Some further bikeshedding might be
needed here—it's late and I'm tired.)I really don't want to see this discussion die as I have a vested
interest in getting this functionality into
Swift 3. So let me suggest that`sequence(_:, next:) -> AdHocSequence`
might be a Swift acceptable solution. We're not going to see
fold/unfold pair happen. It's a given that
`reduce` is a fixed point in Swift space and `sequence` well describes
what this should be doing.So is it possible to push forward with `sequence`, whose only negative
seems to be that it's not as well
loved as `unfold`?