Tracking issue for `Zero`/`One`/`iter_arith` stabilization

[aturon]

We currently have Zero and One traits that are meant to work with Add and Mul and support iterator operations like sum, as well as the current step_by API.

It would be good to have a more comprehensive vision for this kind of trait before stabilization; an RFC would be ideal.

[fizyk20]

Those traits would be really useful for generic arithmetics, I look forward to them being stabilized.

Also, I have some ideas for traits that would pair up with those nicely, e.g.: Field (meaning Add+Mul+Sub+Div+Neg+One+Zero), Vector<T: Field> (meaning Add+Sub+Mul<T>+Div<T>+Neg+Zero), Ring, Group etc. They would allow marking some types as behaving like fields/vectors/what have you - or would such functionality rather belong in a separate crate?

[photino]

I would like to see these are stabilized. They are really useful and simple enough to have a position in std.

[haudan]

I agree with @photino, I don't see a reason why these traits shouldn't be part of std, and like @fizyk20 said, they'll be very useful in generic arithmetics.

[aturon]

Nominating for 1.6 discussion.

[SimonSapin]

I have multiple times tried to use some_iterator.sum(), only to have the compiler remind me that it’s unstable. Then I typically replace it with something like some_iterator.fold(0, std::ops::Add::add).

Please stabilize sum. I care less about what traits support it.

[mitaa]

There is an open issue with iterator sum and product regarding type inference / default type parameter fallback (#25094)

I'm not sure how this impacts stabilization.

[alexcrichton]

Unfortunately the libs team didn't have time to decided on this in the triage meeting, so this won't enter FCP this cycle.

[sfackler]

I'd like to nominate at least Iterator::sum and Iterator::product for stabilization. I believe we can stabilize those even if we're not sure about the Zero and One traits.