-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Numeric traits inconsistent with integer type system #21069
Comments
rust-lang/rfcs#560 proposes: make integers not wrapping but "overflow", and provide separate "wrapping" operations and types. (i.e. I think cc #20795 |
Nominating for 1.0-beta P-backcompat-libs. |
Agreed - might make sense to add Neg to unsigned ints for bitwise stuff. |
1.0 beta, P-backcompats-lib, I-needsdecision |
This commit stabilizes the `std::num` module: * The `Int` and `Float` traits are deprecated in favor of (1) the newly-added inherent methods and (2) the generic traits available in rust-lang/num. * The `Zero` and `One` traits are reintroduced in `std::num`, which together with various other traits allow you to recover the most common forms of generic programming. * The `FromStrRadix` trait, and associated free function, is deprecated in favor of inherent implementations. * A wide range of methods and constants for both integers and floating point numbers are now `#[stable]`, having been adjusted for integer guidelines. * `is_positive` and `is_negative` are renamed to `is_sign_positive` and `is_sign_negative`, in order to address rust-lang#22985 * The `Wrapping` type is moved to `std::num` and stabilized; `WrappingOps` is deprecated in favor of inherent methods on the integer types, and direct implementation of operations on `Wrapping<X>` for each concrete integer type `X`. Closes rust-lang#22985 Closes rust-lang#21069 [breaking-change]
This commit stabilizes the `std::num` module: * The `Int` and `Float` traits are deprecated in favor of (1) the newly-added inherent methods and (2) the generic traits available in rust-lang/num. * The `Zero` and `One` traits are reintroduced in `std::num`, which together with various other traits allow you to recover the most common forms of generic programming. * The `FromStrRadix` trait, and associated free function, is deprecated in favor of inherent implementations. * A wide range of methods and constants for both integers and floating point numbers are now `#[stable]`, having been adjusted for integer guidelines. * `is_positive` and `is_negative` are renamed to `is_sign_positive` and `is_sign_negative`, in order to address rust-lang#22985 * The `Wrapping` type is moved to `std::num` and stabilized; `WrappingOps` is deprecated in favor of inherent methods on the integer types, and direct implementation of operations on `Wrapping<X>` for each concrete integer type `X`. Closes rust-lang#22985 Closes rust-lang#21069 [breaking-change] r? @alexcrichton
This commit stabilizes the `std::num` module: * The `Int` and `Float` traits are deprecated in favor of (1) the newly-added inherent methods and (2) the generic traits available in rust-lang/num. * The `Zero` and `One` traits are reintroduced in `std::num`, which together with various other traits allow you to recover the most common forms of generic programming. * The `FromStrRadix` trait, and associated free function, is deprecated in favor of inherent implementations. * A wide range of methods and constants for both integers and floating point numbers are now `#[stable]`, having been adjusted for integer guidelines. * `is_positive` and `is_negative` are renamed to `is_sign_positive` and `is_sign_negative`, in order to address rust-lang#22985 * The `Wrapping` type is moved to `std::num` and stabilized; `WrappingOps` is deprecated in favor of inherent methods on the integer types, and direct implementation of operations on `Wrapping<X>` for each concrete integer type `X`. Closes rust-lang#22985 Closes rust-lang#21069 [breaking-change]
This commit stabilizes the `std::num` module: * The `Int` and `Float` traits are deprecated in favor of (1) the newly-added inherent methods and (2) the generic traits available in rust-lang/num. * The `Zero` and `One` traits are reintroduced in `std::num`, which together with various other traits allow you to recover the most common forms of generic programming. * The `FromStrRadix` trait, and associated free function, is deprecated in favor of inherent implementations. * A wide range of methods and constants for both integers and floating point numbers are now `#[stable]`, having been adjusted for integer guidelines. * `is_positive` and `is_negative` are renamed to `is_sign_positive` and `is_sign_negative`, in order to address #22985 * The `Wrapping` type is moved to `std::num` and stabilized; `WrappingOps` is deprecated in favor of inherent methods on the integer types, and direct implementation of operations on `Wrapping<X>` for each concrete integer type `X`. Closes #22985 Closes #21069 [breaking-change] r? @alexcrichton
This commit stabilizes the `std::num` module: * The `Int` and `Float` traits are deprecated in favor of (1) the newly-added inherent methods and (2) the generic traits available in rust-lang/num. * The `Zero` and `One` traits are reintroduced in `std::num`, which together with various other traits allow you to recover the most common forms of generic programming. * The `FromStrRadix` trait, and associated free function, is deprecated in favor of inherent implementations. * A wide range of methods and constants for both integers and floating point numbers are now `#[stable]`, having been adjusted for integer guidelines. * `is_positive` and `is_negative` are renamed to `is_sign_positive` and `is_sign_negative`, in order to address rust-lang#22985 * The `Wrapping` type is moved to `std::num` and stabilized; `WrappingOps` is deprecated in favor of inherent methods on the integer types, and direct implementation of operations on `Wrapping<X>` for each concrete integer type `X`. Closes rust-lang#22985 Closes rust-lang#21069 [breaking-change] r? @alexcrichton
From all the integer traits present in
std::num
, onlySignedInt
includesNeg
. TheNeg
trait is not implemented byInt
andUnsignedInt
types because, presumably, it does not make sense to negate unsigned integers. I will not argue whether this is a good policy or not.However, this makes writing generic code for unsigned types harder than it needs to be. For example, suppose we have the function
This function works perfectly (albeit with a warning, but it is valid Rust as far as I can tell) when implemented with a concrete unsigned integer type. However, when making the function generic it stops working:
Changing this to
0 - <expression>
is a simple solution, but one that also does not work very well without pulling other (NumCast
,FromPrimitive
) traits. Another solution is to pull in theNeg
trait directly, but this increases verbosity due toNeg
's associated type machinery. All in all, the lack of unsigned negation complicates things.Now, I accept that you may not want to make unsigned negation common or encouraged behavior. But in that case it also makes no sense to have the
-
operator available at all for unsigned types; users that really want such semantics can replace it by0-<expression>
in non-generic code.My overall point is:
u32
,usize
, etc allow negation, i.e., have theNeg
type implemented, so shouldUnsignedInt
;UnsignedInt
is not meant to be negatable, neither should beu32
,usize
, etc.The text was updated successfully, but these errors were encountered: