Make AdditiveIterator and MultiplicativeIterator extensible

[tbu-]

Previously it could not be implemented for types outside libcore/iter.rs due
to coherence issues.

[rust-highfive]

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

[huonw]

I suspect this change means that sum and product can become methods on just Iterator.

That said, there's deeper structure here: both of these consumers are operating on a monoid: an algebraic structure consisting an (associative) binary operator and an identity element for that operator. Other examples include appending strings/sequences/data structures in general. I idly wonder if approaching this concept from that more perspective may be better, instead of having two essentially identical traits. sum and product could then become thin wrappers around the monoid version. That said, we probably don't want to be so general in std right now.

Thoughts, @aturon?

[aturon]

@tbu- I'm curious what coherence problems you were running into? I presume trying to add a blanket impl of some kind?

We used to have something along the lines @huonw is suggesting, where these worked for types satisfying Add + One or Mul + Zero, but the One and Zero traits were removed as part of moving all aspects of a numeric hierarchy out of std for now. That's also why the traits being modified in this PR are unstable.

[tbu-]

@aturon The problem is that AdditiveIterator needs to be implemented for all iterators of a certain item type – you can't do that though because the Iterator and AdditiveIterator are foreign.

[tbu-]

@huonw Any updates on this one?

[SSheldon]

@tbu-, with #23549 reintroducing Zero and One, you can probably remove your AdditiveIteratorItem and MultiplicativeIteratorItem

[bors]

☔ The latest upstream changes (presumably #23936) made this pull request unmergeable. Please resolve the merge conflicts.

[SSheldon]

@tbu-, what do you think of moving these methods onto the Iterator trait where Item: Add + Zero / Mul + One?

[huonw]

r? @aturon (transferring reviewership, don't have the bandwidth right now.)

[tbu-]

@aturon I made sum and product inherent methods now, should be fine to merge.

[aturon]

@bors: r+

Thanks, @tbu-!

[bors]

📌 Commit 52bb3f7 has been approved by aturon

[alexcrichton]

Could this also omit the T type parameter? I think something like this in theory shouldn't ICE:

fnsum<S=Self::Item>(self) -> SwhereS:Add<Self::Item,Output=S> + Zero,Self:Sized{
...}

[tbu-]

@alexcrichton Indeed. Changing it right now.

[alexcrichton]

Nice!

[SSheldon]

Does the output of Add need to be the same as the Item of the iterator? Could this be: fn sum(self) -> <Self::Item as Add>::Output where Self::Item: Add, Self::Item::Output: Zero

Not sure it's that worth it, but it'd allow summing when the output and input are different.

[tbu-]

The S=... part is just setting a default for the type parameter. Iterator type and type that is being summed over can be different in the code.

[SSheldon]

But the Output=S part requires that the iterator's Item and the Output of Add be the same

[SSheldon]

Ohhh I understand it now :) Disregard!

[alexcrichton]

@bors: r+ 4b8a918

[bors]

⌛ Testing commit 4b8a918 with merge 82d1a5e...

[bors]

💔 Test failed - auto-mac-32-opt

[tbu-]

@alexcrichton Sorry for the inconvenience, make checked now.

[alexcrichton]

@bors: r+ 97f24a8

No worries!

[bors]

⌛ Testing commit 97f24a8 with merge dd6c4a8...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt