Re: [swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

Sent from my iPad > On Jul 6, 2016, at 6:50 PM, Dave Abrahams via swift-evolution > wrote: > > >> on Wed Jul 06 2016, Dave Abrahams wrote: >> >> Finally, as mentioned earlier we could easily supply a protocol that >> makes it no harder than conforming to

Re: [swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

on Wed Jul 06 2016, Dave Abrahams wrote: > Finally, as mentioned earlier we could easily supply a protocol that > makes it no harder than conforming to IteratorProtocol is. You don't > even need to make your iteration state equatable because we can compare > counters stored in the indices.

Re: [swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

on Wed Jul 06 2016, Anton Zhilin wrote: > 1. Do nothing with finiteness, because huge sequences are mostly like > infinite ones, plus because infinite loops are useful > 2. Allow collections to be infinite > 3. Do not add new fields to collections, because infinite loops are > useful No

Re: [swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

1. Do nothing with finiteness, because huge sequences are mostly like infinite ones, plus because infinite loops are useful 2. Allow collections to be infinite 3. Do not add new fields to collections, because infinite loops are useful 4, Do not separate protocols Current model of IteratorProtocol

[swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

This post describes the standard library team's analysis of the finite/infinite sequence issue raised by Matthew Johnson and others in http://news.gmane.org/find-root.php?message_id=1976B8AE%2dFDD1%2d4257%2dA24F%2d2AFF84115445%40anandabits.com. [Dmitri is going to write a separate post detailing