Pitch: Sequence enhancements: chaining, repeating, batching

[bitjammer (Ashley Garland)]

Looks pretty good. I'll send you my gists tomorrow so we can compare.

[Dante-Broggi]

The problem with calling next() repeatedly on an iterator that has returned nil is that back in swift 1 it was a programmer error to do so.
And then they realized that IIRC Zip2Iterator was violating this, and changed to "if it has returned nil it must return nil indefinitely"

[Karl]

@allevato

If you call a.followed(by: b).followed(by: c).followed(by: d).followed(by: e), you’ve constructed a type that looks something like ConcatenatedSequence<ConcatenatedSequence<ConcatenatedSequence<ConcatenatedSequence<A, B>, C>, D>, E>. I would imagine that would have some effects on type checker performance.

Shouldn’t do. A single lazy flatmap returns something massive like that, too.

@allevato

The key observation is that when you’ve concatenated two sequences in this fashion, you don’t care about the original sequence types anymore—just the element type.

If you erase the sequences, you lose the ability to make the result conditionally conform to things like RandomAccessCollection. You’ve basically remade “joined”.

[allevato (Tony Allevato)]

@Karl

If you erase the sequences, you lose the ability to make the result conditionally conform to things like RandomAccessCollection.

This is an excellent point that I hadn't considered.

[Erica_Sadun]

Updated proposal here: (removed)

• Feedback requested
• If belong on the author list, let me know (I'll need a github user url)

I have a strong feeling @Joe_Groff or @Douglas_Gregor will quickly say "Break it down into three proposals instead" , so I'm user-name pinging them. I also suspect they will say "Expand the motivation section".

• Since the batched and appending items are not originally sourced from my first proposal, please send me some great motivation and examples.

I apologize for any harm I have caused by creating the draft of a unified proposal.

[Lily_Ballard]

@Erica_Sadun

Paging @Kevin_Ballard to the white sequence courtesy phone.

Without having read the rest of this thread, calling next() on an exhausted iterator (i.e. one that has returned nil in the past) used to be unsafe (or rather, implementation-defined), but some time ago (Swift 2.0 maybe?) it was redefined as being explicitly safe. From the documentation on IteratorProtocol.next():

Repeatedly calling this method returns, in order, all the elements of the underlying sequence. As soon as the sequence has run out of elements, all subsequent calls return nil.

[jack (Jack Lawrence)]

A few years ago it used to be the case that calling next() after exhaustion was undefined, but a year or so ago the documentation/requirement was changed so that next() could be called after exhaustion and it would continue returning nil.

[bitjammer (Ashley Garland)]

I really would've wished you had asked me before putting my name on a proposal. I understand you were already working on cycling but I wasn't intending on trying to compete with your proposal. I'm not sure we were done discussing the other items. At any rate, I think you can take it from here, thanks.

[Erica_Sadun]

@bitjammer

I really would’ve wished you had asked me before putting my name on a proposal. I understand you were already working on cycling but I wasn’t intending on trying to compete with your proposal. I’m not sure we were done discussing the other items. At any rate, I think you can take it from here, thanks.

It's just a gist, not a proposal. I'm happy to return it to the previous form and apologize for any discomfort I have caused.

[bitjammer (Ashley Garland)]

No worries, please run with it.

[Erica_Sadun]

Again, it's just a draft to move the discussion forward. Just let me know what you are and are not comfortable with and I'll update accordingly.

[bitjammer (Ashley Garland)]

I think I'm going to take a step back from the discussion for the time being. If you're interested in seeing these APIs through, then please do add them to your proposal. You can leave my name off, if you would. Thanks!

[Erica_Sadun]

Removed as you requested. Still happy to hear feedback and suggestions.

Normally when someone asks to be removed, there's something fundamentally flawed with the proposal. Is there anything in particular I can fix or parts that stand out as something you don't want to associate with?

[bitjammer (Ashley Garland)]

I like where the proposal is headed. Thanks for asking!

[bob]

I really like the idea of replication of itertools for Swift. Unfortunately, the generality of itertools will be pretty much impossible to achieve without variadic generics. This proposal is not worth it if everything needs to by type-erased.

Like itertools, in Swift's version all operations should be as lazy as possible, consuming Sequences only when necessary. With regard to exhausting single-pass iterators, I believe that itertools's behavior is to store a copy of the results as they are produced, and then to return the copies as needed (for repeat, for instance).

[Erica_Sadun]

For anyone tracking this topic, I am deliberately sitting on this proposal until @Dave_Abrahams1 has time for feedback on this forum thread: [Pitch] Make Collection Super-Convenient and Retire Sequence