> 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. If it can't offer value semantics, then you should write it as a class so those reference semantics are obvious. 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. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
