Add Update adaptor and `update()` method

[Enet4]

This resolves #487. The sequential version created by the producer is based on the itertools implementation. Tests are included, but let me know if you'd like better coverage.

[cuviper]

This looks great, thanks!

I do want a few more tests just for uniformity, adding this to tests/clones.rs, tests/debug.rs, tests/producer_split_at.rs, and tests/compile-fail/must_use.rs. I expect this will behave fine though. :)

[cuviper]

This looks great, thanks!

I do want a few more tests just for uniformity, adding this to tests/clones.rs, tests/debug.rs, tests/producer_split_at.rs, and tests/compile-fail/must_use.rs. I expect this will behave fine though. :)

[cuviper]

nit: I don't think you need either mut here. par_iter will be moved into collect(), and x is already &mut.

[cuviper]

Did you consider using itertools directly? We wouldn't want a public dependency, but this is behind the scenes. But the implementation is pretty straightforward, so I'm just wondering what you think.

[Enet4]

I did think about that while reading the issue. I chose to replicate the implementation because interleave did the same, although with additional reasons.

If there is willingness to depend on itertools in future versions, I suppose this adaptor would take advantage of that. Although it's just my opinion, leaving these adaptors behind a feature gate to keep itertools an optional dependency feels a bit unnecessary.

[cuviper]

Also, just to keep related behavior grouped together, let's move this up after inspect.

[Enet4]

The requested adjustments were made. Please let me know if you'd like a commit squash.

As for the actual use of itertools, if you find that keeping it as a dependency is ok, I can make the necessary changes.

[cuviper]

Thanks! We don't need to worry much about itertools -- we can always change this later if wanted.

bors r+

[bors]

Build succeeded

• continuous-integration/appveyor/branch
• continuous-integration/travis-ci/push