IteratorProtocol imposes some strange limitations and preconditions which basically boil down to "this protocol is fundamentally mutating, but we don't want to promise whether you're going to get value or reference semantics, so don't do anything that might behave differently depending on that, and by the way we can't possibly enforce that in the type system, so good luck finding any mistakes yourself". As far as I can tell, this is because some iterators *must* provide reference semantics (e.g. when reading from a socket), while others can be implemented perhaps more efficiently with a value type.
How bad would it be to force all iterators to provide reference semantics by making IteratorProtocol a class protocol? Particularly if we assume that iterators could generally be made `final`? Alternatively, how valuable is it to specify that you can't use an iterator in a way that would expose whether it is a reference or a value type? The only iterators I can think of which would *need* to be reference types are ones which draw elements from an outside source; for those, it's unsurprising that copying doesn't "work". Are there cases I'm not thinking of? Or have I totally misread the situation in some way? -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
