Add Stream::unzip

[tirr-c]

Iterator::unzip collects elements in Default + Extend containers, but here I used FromStream on bound channels with no capacity.

[yoshuawuyts]

Ref #129.

@tirr-c Thanks so much for starting this! Could you say more about why you chose to change the trait bounds? We've just merged #211, which makes it possible to use in the bounds.

Heh also def seems like this would pair up nicely with the channel design in #212! (though we shouldn't block ourselves on it I think).

[tirr-c]

@yoshuawuyts I first thought that Default + Extend bounds meant it'll make a new container and extend from some iterator (or stream), so I used FromStream instead.

I've just checked out the implementation of Iterator::unzip. Surprisingly it was using Extend as an abstraction of element addition! So we can even use Default + std::iter::Extend for the container bounds.

[yoshuawuyts]

So we can even use Default + std::iter::Extend for the container bounds.

Not necessarily -- if Extend is implemented for some kind of database handle then std::iter::Extend would not be suitable. I think if we want people to be able to experiment with building networked streaming patterns we keep it as Default + Stream::Extend.

Refs

• std::iter::Iterator::unzip impl

[tirr-c]

If we're not given any existing database handle, we need to build a new handle from its default impl; that isn't what we want, I think. How about unzip returning two streams?

[tirr-c]

This PR is superseded by #543.