Unified machine word trait #1676
Conversation
|
This is the same as the Meanwhile you could use num_traits::PrimInt as a substitute, if you don't need to use every method (e.g. saturating_add etc). (One of the goals of #369 was to provide "Limited generic programming: being able to work generically over the natural classes of primitive numeric types that vary only by size." But then the remaining traits proposed in #369 were removed as well |
| fn bitwise_and(self, Self) -> Self; // new | ||
| fn bitwise_not(self) -> Self; // new | ||
| fn bitwise_or(self, Self) -> Self; // new | ||
| fn bitwise_xor(self, Self) -> Self; // new |
There was a problem hiding this comment.
Why not simply make the trait implement BitAnd, Not, BitOr and BitXor?
You could call a.bitand(b) if you don't want to write a & b.
|
I think this trait should be proposed as part of a comprehensive numerics proposal to adds all traits for numerics. I don't think we can evaluate this trait without thinking about how it overlaps and interacts with potential traits like |
|
@withoutboats According to philosophies of numerical computing proposed by John L. Gustafson in his book The End of Error: Unum Computing, there is merit in separating algebraic properties of the idealized numeric datatypes, from the "fast, dirty and specific" machine instructions. In particular, we want algebraic operations to obey algebraic laws, while we want machine instructions to do one particular job in the right situation. This is particularly egregious in floating point optimizations that might insert a fused multiply-add whenever you write addition and multiplication in the same expression. Problem with FMA is that it does not obey algebraic laws (yields different results than multiply followed by add, due to rounding) but provides a more accurate result overall. The point of having a separate machine word trait is to separate concerns: the numeric hierarchy can focus on algebra, while this trait aims to be as close to metal as possible. If there was to be a |
|
@magnetohydrodynamics I don't disagree, I just think the whole system should be proposed concurrently, so we can discuss it holistically. This RFC contains this proposal by its omission, which is hard to evaluate without seeing the other traits:
|
| - Make it easy to implement `i128`/`u128` (and larger types) when compiler/hardware support permits, letting | ||
| generic code predating the addition of the larger types work with it. | ||
| - Generic implementation of `std::ops::*` traits with the usual panic-on-overflow semantics, using the | ||
| `checked_*` functions. |
There was a problem hiding this comment.
This could be more explicit about the benefits. What kind of code needs to work with generic overflow and what will be better about it? How does this trait make it easier to implement large integers in software? Why are generic ops traits desirable?
|
Neat proposal. Thanks for writing it up @magnetohydrodynamics! Why does Do you have an implementation already? It might be good to prove this serves its purpose well in real generic code. This is proposing a lot of new functions. It may be more appropriate and require less debate to consider the unification of existing features independently of adding new features. The RFC should say where the trait will end up. |
| [summary]: #summary | ||
|
|
||
| Unify functionality peculiar to `i8`…`i64` and `u8`…`u64` in a trait containing the | ||
| family of `overflowing`/`checked`/`wrapping`/`saturating` variants of arithmetic operations, |
There was a problem hiding this comment.
What about inheriting these from the existing traits instead of duplicating them?
There was a problem hiding this comment.
I don't think there are existing standard traits for the overflowing/checked/wrapping/saturating methods.
There was a problem hiding this comment.
Oh, woops! I must still be thinking in pre-1.0 land.
|
ping @aturon @Karl-D-Asmussen status? |
|
Appears |
|
Thanks much for the RFC. As some others have mentioned, numeric traits like this have had a long, sad history in the standard library. The strong preference of the libs team has been for both generic numeric programming, and a numeric hierarchy, to live outside of the standard library, at least at first. If such an external crate saw widespread use, we could imagine moving it into the standard library. But we've gotten it wrong too many times to start immediately with As such, I'm going to propose closing this RFC for the time being, in favor of development in crates.io. @rfcbot fcp close |
|
Team member @aturon has proposed to close this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
|
We discussed this RFC in libs triage, and in general there was consensus around the previous summary; we don't feel ready to revisit this question in the standard library, and would much prefer this to be developed out of tree. I'm going to close, in the meantime. |
A proposal to unify functionality pertaining to the primitive types in a single trait, easing generic programming with primitive types.