> On Jun 28, 2016, at 3:33 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> This use case seems interesting enough to at least deserve some >> consideration before we decide to require iterators to have reference >> semantics. IMO the fact that `next` is a mutating requirement provides a >> pretty strong indication of the destructive / consuming semantics of using >> an iterator. Requiring reference semantics gives up flexibility and I’m not >> completely convinced it adds clarity (but still keeping an open mind about >> this). > > My feeling is that, except for the trivial case of IndexingIterator and other > iterators over collections, all iterators *should* need reference semantics. > If your iterator can offer value semantics, then you should convert it into a > Collection to gain the benefits of indices.
Assuming we are going to pin down the requirement that Collection be finite (in the sense that iterating over the whole collection is practical in a real program running on a real device that is available today) then it is trivial to come up with value semantic iterators that cannot conform to Collection. For example, iterators over infinite mathematical sequences. > If it can't offer value semantics, then you should write it as a class so > those reference semantics are obvious. I agree with this. > This would get rid of the really ugly caveat that's always festered at the > heart of Iterator: > >>>> Obtain each separate iterator from separate calls to the sequence's >>>> makeIterator() method rather than by copying. Copying an iterator is safe, >>>> but advancing one copy of an iterator by calling its next() method may >>>> invalidate other copies of that iterator. for-in loops are safe in this >>>> regard. > > The underlying cause of this requirement is that you can't know whether a > given iterator is a value type or a reference type. Let's fix that. I would like to see us eventually have a way to specify a generic constraint indicating value semantics regardless of what happens with iterators. If we gain that capability you *can* know that you have a value semantic iterator when you use that constraint. I am not firmly opposed to making iterators require reference semantics but I don’t think the pros and cons have been thoroughly discussed on the list yet so I am pointing out what I think are interesting use cases for value semantic iterators. Swift is a language that embraces value semantics. Many common iterators *can* be implemented with value semantics. Just because we can’t implement *all* iterators with value semantics doesn’t mean we should require them to have reference semantics. It just means you can’t *assume* value semantics when working with iterators in generic code unless / until we have a way to specify a value semantics constraint. That’s not necessarily a bad thing especially when it leaves the door open to interesting future possibilities. -Matthew > > -- > Brent Royal-Gordon > Architechies > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
