Implement compile time function evaluation (CTFE) #11621
Labels
E-hard
Call for participation: Hard difficulty. Experience needed to fix: A lot.
I-compiletime
Issue: Problems and improvements with respect to compile times.
P-low
Low priority
Comments
brendanzab
added a commit
to brendanzab/rust
that referenced
this issue
Jan 17, 2014
This removes the `Primitive::{bits, bytes, is_signed}` methods and removes the operator trait constraints, for the reasons outlined below:
- The `Primitive::{bits, bytes}` associated functions were originally added to reflect the existing `BITS` and `BYTES` statics included in the numeric modules. These statics are only exist as a workaround for Rust's lack of CTFE, and should probably be deprecated in the future in favor of using the `std::mem::size_of` function (see rust-lang#11621).
- `Primitive::is_signed` seems to be of little utility and does not seem to be used anywhere in the Rust compiler or libraries. It is also rather ugly to call due to the `Option<Self>` workaround for rust-lang#8888.
- The operator trait constraints are already covered by the `Num` trait.
bors
added a commit
that referenced
this issue
Jan 18, 2014
As part of #10387, this removes the `Primitive::{bits, bytes, is_signed}` methods and removes the trait's operator trait constraints for the reasons outlined below: - The `Primitive::{bits, bytes}` associated functions were originally added to reflect the existing `BITS` and `BYTES`statics included in the numeric modules. These statics are only exist as a workaround for Rust's lack of CTFE, and should be deprecated in the future in favor of using the `std::mem::size_of` function (see #11621). - `Primitive::is_signed` seems to be of little utility and does not seem to be used anywhere in the Rust compiler or libraries. It is also rather ugly to call due to the `Option<Self>` workaround for #8888. - The operator trait constraints are already covered by the `Num` trait.
tweber12
pushed a commit
to tweber12/rust
that referenced
this issue
Jan 18, 2014
This removes the `Primitive::{bits, bytes, is_signed}` methods and removes the operator trait constraints, for the reasons outlined below:
- The `Primitive::{bits, bytes}` associated functions were originally added to reflect the existing `BITS` and `BYTES` statics included in the numeric modules. These statics are only exist as a workaround for Rust's lack of CTFE, and should probably be deprecated in the future in favor of using the `std::mem::size_of` function (see rust-lang#11621).
- `Primitive::is_signed` seems to be of little utility and does not seem to be used anywhere in the Rust compiler or libraries. It is also rather ugly to call due to the `Option<Self>` workaround for rust-lang#8888.
- The operator trait constraints are already covered by the `Num` trait.
|
Nominating. The "P-backcompat-lang" should be removed. CTFE is a post-1.0, backwards-compatible feature. |
|
Re-assigning as P-low Also, as something that really would require an RFC, we may want to move it to an issue on that repo, depending on what policy we decide on there. Cc @brson |
|
@nick29581 Should this be moved to rust-lang/rfcs? (There is already rust-lang/rfcs#322 though.) |
|
Closing in favour of rust-lang/rfcs#322 |
2 tasks
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Oct 21, 2023
…ut-closure-non-async-fn, r=blyxyas Needless pass by ref mut closure non async fn Fixes rust-lang/rust-clippy#11620. Fixes rust-lang/rust-clippy#11561. changelog: [`needless_pass_by_ref_mut`]: Correctly handle arguments moved into closure in non-async functions. r? `@Centri3`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a big gap in Rust's current support of zero cost abstractions, and something that puts us behind languages such as D or C++. This would for example allow us to deprecate the
std::uint::{bits, bytes}statics in favor of using thestd::mem::size_offunction. It would also allow for the use of overloaded operators in constexprs, which would in turn allow us implement the base numeric arithmetic operators within the standard library, as opposed to relying on compiler magic (see #11526).The text was updated successfully, but these errors were encountered: