on Wed Jul 20 2016, Dave Abrahams <dabrahams-AT-apple.com> wrote: > on Wed Jul 20 2016, Jonathan Hull <jhull-AT-gbis.com> wrote: > >>> >>> Basically, I added back in a super-minimal protocol to fill the >>> >>> structural gap left by Sequence. I call it “IteratorProvider” and it >>> >>> only has a single function which vends an iterator. Collection >>> >>> adheres to this, and Iterator adheres to it by returning itself. All >>> >>> of the other methods from Sequence remain on Iterator. Thus anyone >> >>> >>> with API that only needs a single pass would take a IteratorProvider >>> >>> and then work on the iterator it provides. >>> >> >>> >> That leaves us back where we are now: people will see that >>> >> IteratorProvider is a simple, universal protocol for both single-and >>> >> multi-pass sequences, write algorithm libraries that depend on >>> >> multi-pass-ness, and test them with the most prevalent examples, which >>> >> happen to be multi pass. >>> > >>> > Let me make a quick counter-argument, because I thought about it a >>> > bit, and I don’t think it does have the same problem (especially with >>> > careful/better naming). >>> > >>> > The difference is that the ONLY method on IteratorProvider is the one >>> > to get an iterator. There is no map, filter, sort, first, count, etc… >>> > just a way to get a single-pass iterator. This changes the mindset >>> > when using it. You are aware that you are getting a single-pass >>> > iterator. >>> >>> Maybe. What's to stop people from extending IteratorProvider? >> >> Nothing. But that is true of any protocol. I am ok with individual's >> extensions. They would have to use that single method to build up >> from anyway, so presumably they would have to consider the single pass >> case in their extensions... >> >>> > True, people might try to get the iterator a second time, but we can >>> > make the iteratorProvider method optional (and trying to get an >>> > iterator from an iterator which is spent would return nil) >>> > and then they are forced to deal with the case where it was >>> > single-pass. >>> >>> Now you can't loop over the same array multiple times. >> I must be missing something. Isn’t that the point? > > No. Arrays are multipass. > >> I mean, your version is called “IterableOnce”. Why do you want to >> iterate on IterableOnce more than once? > > Because it happens to be multipass. > >> The point (at least in my mind) is to provide a common interface for >> things that we want to iterate over a single time. If you want to >> iterate multiple times, use collection’s interface where you are >> guaranteed multi-pass. > > for ... in uses Iterators. > >> That said, you actually can loop multiple times for collections by >> getting a new iterator from the provider (which could point to the >> same array storage). The optional just forces you to check for the >> single-pass case. > > Oh, I'm sorry; I didn't realize you were saying that only single-pass > IteratorProviders would ever return nil from their methods.
Note: any IteratorProvider that could return nil would have to be a class (or wrap a class) in order to bypass mutability restrictions, since we can't allow the method that provides the iterator to be mutating. >> I have a feeling like I am missing your true meaning here though... > > Probably a communication failure on my end. -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
