Repository navigation
const fn tracking issue (RFC 911) #24111
Description
Activity
Is this closed by #25609?
@Munksgaard That just adds support to the compiler AFAIK. There's a lot of functions in the stdlib that need to be changed to
const fnand tested for breakage. I don't know what the progress is on that.I'm hoping this to be implemented on
std::ptr::null()andnull_mut()so that we can use them to initializestatic mut *MyTypeWithDropwithout resorting to0usize as *mut _Reacted by Kornel, Dan Kolsoi, Zac Pullar-Strecker, Hunar Roop Kahlon, james gilles, Mariell Hoversholm, Onur Şahin and Christian SchmidtTo be clear, the question here is not primarily about the usefulness of the feature but rather regarding the best way to formulate it (or the best framework to formulate it in). See the RFC discussion.
This is now the tracking issue for eventual stabilization.
#29107 has been closed.
I disagree that "Integration with patterns", or any changes to the standard library should block this. This is very useful even without those changes, and those changes can be done later. In particular, I would like to start using
const fnin my own code soon.Accordingly, could the stabilization status of this be re-evaluated?
Reacted by Sander Maijers, Benjamin Fry, Michael K, Tim Hutt and Michael LeonardI don't doubt that
const fneven in its current limited form would be useful functionality to have, but what I would really like, ideally before going further along this path, would be for those in favor of "theconst fnapproach" to think about and articulate their preferred endgame. If we just keep on incrementally adding useful-seeming functionality in the most obvious way, it seems very likely to me that we'll eventually end up copying more or less the entirety of C++'sconstexprdesign. Is that something we are comfortable with? Even if we say yes, I would much rather that we choose that path in a clear-eyed way, instead of backing into it with small steps over time, as the path of least resistance, until it has become inevitable.(Given that the semantics of safe Rust code should be fully definable, it seems likely that eventually at least every function which doesn't (transitively) depend on
unsafeshould be able to be marked asconst. And given thatunsafeis supposed to be an implementation detail, I bet people will push for somehow loosening that restriction as well. I would much rather we looked abroad and tried to find a more cohesive, capable, and well-integrated story for staging and type-level computation.)Reacted by Nelo Mitranim, Matt Ickstadt, Alexis Hunt and Liam Diprose278 remaining items
Related: #57261
Does someone know what happened to the
const_string_newfeature? Is there a tracking issue for it? The unstable book just links here.- The issue should be open then. It's just insulting as a user to be pointed to a closed issue.…On Wed, Jan 9, 2019, 04:05 Mazdak Farrokhzad ***@***.*** wrote: @phansch <https://github.com/phansch> That's because all rustc_const_unstable point here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n7JhzsZZpizmWlp0Nww5bcfIqH2Vks5vBbC8gaJpZM4D66IA> .
@durka: There's always going to be a possible window where something is closed in nightly and the resolution still hasn't landed in stable. How is that insulting?
Reacted by Jake Goulding, Phil Hansch, Ryan Hiebert and Adam GausmannReacted by Nathan LilienthalI've been resisting commenting here, and maybe we should move this conversation to a thread on internals (is there one already?) but...
The decision to close this makes no sense to me. It's a tracking issue, because it shows up in error messages from the compiler, and it's not alone, see this post for some more examples: https://internals.rust-lang.org/t/psa-tracking-for-gated-language-features/2887. Closing this issue to me implies stability, which is obviously not yet the case.
I frankly can't see an argument for closing this... I'm glad more targeted issue now exist, so implementation can move forward, with hopefully new discussion and focus, but I don't see a clear way to associate the compiler messages with those.
Again, if this needs (or already has) a thread on internals maybe let's move this conversation there?
EDIT: Or is the issue just that the book is outdated? Trying the example from the RFC (it's missing a couple
#[derive(...)]s) seems to work without errors on Rust rustc 1.31.1. Are there still compiler error message pointing here? It would be nice to have a place to link errors like:error: only int, `bool` and `char` operations are stable in const fnIf we want to have them linked to the specific issues that would be an improvement possibly.
Ok, so here should be some strong evidence for this issue remaining open. As far as I can tell this:
rust/src/libsyntax/feature_gate.rs
Line 194 in 6ecad33
is the only
activefeature that points to a closed issue.In an ideal world I believe these kinda of discussions should really be automated, since as we've discovered, people have varying opinions and ideas about how things should work. But that's really not a conversation for this thread...
If we want to have them linked to the specific issues that would be an improvement possibly.
Yes, this is the correct solution, and what @Centril already suggested.
The initial comment has also been edited to redirect people to the specific issues who arrive here in the "window" that @ErichDonGubler mentions.
Someone could edit the issue body here to prominently link to #57563 then?
@glaebhoerl done :)
Reacted by Gábor LehelHi, I got here because I got
error[E0658]: const fn is unstable (see issue #24111)when compiling ncurses-rs. What should I do? Upgrade rust? I've got$ cargo version cargo 1.27.0 $ rustc --version rustc 1.27.2EDIT: did
brew uninstall rustand followed rustup install instructions, nowrustc --versionisrustc 1.33.0 (2aa4c46cf 2019-02-28)and that error went away.Yes, in order to be able to use
const fnon stable, you'll need to update your compiler.I am coming from Zig where you can use iterators and functions like sin at compile time. However, attempting to do this in rust gives the following errors. Are these planned to be added to the language at some point? I haven't found an issue mentioning these so I figured I'd post here.
cannot call non-const fn `<std::ops::Range<usize> as Iterator>::next` in constant functions --> src/main.rs:9:14 cannot call non-const fn `f64::<impl f64>::sin` in constant functions
#57563 | new meta tracking issue
Old content
Tracking issue for rust-lang/rfcs#911.
This issue has been closed in favor of more targeted issues:
Locals, assignments, destructuring: Tracking issue for RFC 2341, Allow locals and destructuring in const fn #48821const fnintegration with pattern matching #57240#![feature(const_fn_floating_point_arithmetic)]#57241loopin constant evaluation" #52000ifandmatchin constants" #49146usizecasts: [tracking issue] raw ptr to usize cast inside constants #51910unionfield access insideconst fn#51909&mut Treferences and borrows: Tracking issue for&mut Tin const contexts (const_mut_refs) #57349Things to be done before stabilizing:
const unsafe fndeclaration order unsafe const fn declaration order #29107CTFE = https://en.wikipedia.org/wiki/Compile_time_function_execution