[swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib
kevin at sb.org
Fri May 13 14:07:29 CDT 2016
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 at 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
>> 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) ->
>> However, the comment implies that the second one should instead
>> be this:
>> public func unfold<T>(_ initialElement: T, applying: T -> 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) ->
>> 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`?
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?) ->
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution