imagine being the person responsible for designing the `core::iter` module, arguably the most impactful piece of engineering not bundled into the compiler somehow, and special-casing FusedIterator for "this does not resume" instead of ReIterator for "this does resume"
Conversation
Replying to
would it actually work to have Iterator making a stronger API guarantee than ReIterator? or would you just not have ReIterator extend Iterator?
2
Iterator could guarantee None being returned after the first time it's returned. It would require adding extra state and checks to certain iterators and iterator adaptors. It wouldn't simply get optimized out and it would make them a bit more difficult to write correctly.
1
I wanted it to feel like using iterators in Python with even more convenience from method chaining and having all of the itertools and itertools docs functionality built into it.
Python notably doesn't provide that guarantee and doesn't offer an adaptor for it. Not very useful.
It was also meant to offer functionality available in Boost.Range and D ranges for double-ended (consume from both ends, reverse) and random access iterators.
Random access doesn't fit well into the ownership/lifetime model and what they did with it wasn't what was intended.