search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
97.46k stars 12.6k forks source link

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

Closed aturon closed 8 years ago

aturon commented 9 years ago

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.

regexident commented 8 years ago

Just to add another use-case of One and Zero that's completely unrelated to iteration to the discussion:

While BitAnd/BitXor/BitOr/Shl/Shr/… are useful for manipulating existing binary values in a generic way One and Zero are essential and necessary for creating new binary values in a generic way (and Mul of little importance in this context).

aturon commented 8 years ago

I agree wholeheartedly with @alexcrichton -- at this point, with this tracking issue, we should focus on landing support for ergonomic sum and product methods analogous to collect. In the future, we can explore numeric hierarchies and other conveniences, and probably even provide blanket impls translating from one to another (given lattice impl specialization.)

alexcrichton commented 8 years ago

The libs team discussed this issue during triage yesterday and the decision was to stabilize. We realize that the FCP for this issue was pretty short, however, so please comment with any objections you might have! We're very willing to backport an un-stabilization for the few APIs we have this cycle.

Specifically, we're thinking of stabilizing the sum and product methods while leaving the trait they reference unstable for one more cycle (just to make sure)

nagisa commented 8 years ago

I feel that something monoid-identity like might not be a good match for Range, because using identity of (T, ·) with operation of (T, +) might not make complete sense ∀T. However, to me it seems like making One a trait One: Mul and Zero a trait Zero: Add (the num crate model) makes more sense than having them be stand-alone even given what I said above.

What is really desired for Range is semi-ring (T, +, ·), but I’m doubtful anybody is interested in pulling in the whole type theory into Rust.

SimonSapin commented 8 years ago

@alexcrichton So, stabilizing without any of the API changes proposed here?

sfackler commented 8 years ago

@SimonSapin No, we're moving to the collect-style helper trait: https://github.com/rust-lang/rust/pull/34530/files#diff-a9700f0b651bcc35126d8a52ae81bc78R527