[swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

Kevin Ballard kevin at sb.org
Sat May 14 15:08:18 CDT 2016

AnySequence is specifically used to erase the type of an underlying
sequence, and I'm guessing that using it here will make it harder to
optimize loops that use this.
-Kevin Ballard
On Fri, May 13, 2016, at 10:20 PM, Patrick Smith wrote:
> Would there be any issue with the return type being AnySequence? It’s
> used in other areas:
> LazySequence & FlattenSequence’s
> dropFirst(n: Int) -> AnySequence<Generator.Element>
> dropLast(n: Int) -> AnySequence<Generator.Element>
> No need to introduce another type, and it’s straight forward to
> implement with AnySequence.
>> On 14 May 2016, at 5:07 AM, Kevin Ballard via swift-evolution <swift-
>> evolution at swift.org> wrote:
>> 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
>>>>> `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`?
>> 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
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/43ba994d/attachment.html>

More information about the swift-evolution mailing list