Since the iterators that are generated by tee may be consumed at different rates, the tee struct will need to remember a portion of the results from underlying iterator (the lag between the faster and slower iterators). A naive solution would just remember the entire underlying iterator, a better solution would use something like a double ended queue.
Thread safety is out of scope unless you think it should be in scope and can covince me.
Is your feature request related to a problem? Please describe.
It's possible users would like to use an iterator more than once. Be using
tee
as inspiration we can have that behaviour in go-functional.Describe the solution you'd like
Does this incur a breaking change?
No.
Do you intend to build this feature yourself?
If no one else picks it up.
Additional context
Since the iterators that are generated by
tee
may be consumed at different rates, thetee
struct will need to remember a portion of the results from underlying iterator (the lag between the faster and slower iterators). A naive solution would just remember the entire underlying iterator, a better solution would use something like a double ended queue.Thread safety is out of scope unless you think it should be in scope and can covince me.