const fn tracking issue (RFC 911)

#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 #48821~~
Integration with patterns: Tracking issue for const fn integration with pattern matching #57240
Floating points: Tracking issue for #![feature(const_fn_floating_point_arithmetic)] #57241
Panics: Tracking issue for RFC 2345, "Allow panicking in constants" (const_panic) #51999
Loops: Tracking issue for RFC 2344, "Allow loop in constant evaluation" #52000
Control flow: Tracking issue for RFC 2342, "Allow if and match in constants" #49146
Comparing raw pointers: Tracking issue for comparing raw pointers in constants #53020
Dereferencing raw pointers: [tracking issue] dereferencing raw pointers inside constants (const_raw_ptr_deref) #51911
Raw pointer to usize casts: [tracking issue] raw ptr to usize cast inside constants #51910
Union field accesses: [tracking issue] union field access inside const fn #51909
Warnings on long running evaluations: [tracking issue] warnings on long running constant evaluations #49980
Constant propagation not causing errors: Tracking issue for constant prop not causing add'l errors (RFC #1229) #28238
&mut T references and borrows: Tracking issue for &mut T in const contexts (const_mut_refs) #57349

Things to be done before stabilizing:

Reach final decision :P
const unsafe fn declaration order unsafe const fn declaration order #29107
write docs

CTFE = https://en.wikipedia.org/wiki/Compile_time_function_execution

Is this closed by #25609?

@Munksgaard

@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 fn and tested for breakage. I don't know what the progress is on that.

I'm hoping this to be implemented on std::ptr::null() and null_mut() so that we can use them to initialize static mut *MyTypeWithDrop without resorting to 0usize as *mut _

To 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.

Rollup merge of rust-lang#28507 - Manishearth:const-stable, r=alexcri…

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 fn in my own code soon.

Accordingly, could the stabilization status of this be re-evaluated?

I don't doubt that const fn even 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 "the const fn approach" 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++'s constexpr design. 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 unsafe should be able to be marked as const. And given that unsafe is 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.)

Related: #57261

Does someone know what happened to the const_string_new feature? Is there a tracking issue for it? The unstable book just links here.

@phansch

@phansch That's because all rustc_const_unstable point here. (cc @oli-obk can we fix that?)

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

@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?

I'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 fn

If 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

(active, const_fn, "1.2.0", Some(24111), None),

is the only active feature 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.

#57563 has now been opened to track the remaining unstable const features.

Rollup merge of rust-lang#57564 - varkor:update-const_fn-tracking-iss…

Someone could edit the issue body here to prominently link to #57563 then?

@glaebhoerl

@glaebhoerl done :)

Hi, 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.2

EDIT: did brew uninstall rust and followed rustup install instructions, now rustc --version is rustc 1.33.0 (2aa4c46cf 2019-02-28) and that error went away.

Yes, in order to be able to use const fn on 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

Navigation Menu

Repository navigation

const fn tracking issue (RFC 911) #24111

#57563 | new meta tracking issue

Old content

278 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

const fn tracking issue (RFC 911) #24111

Description

#57563 | new meta tracking issue

Old content

Activity

Munksgaard commented on Jun 20, 2015

abonander commented on Jul 2, 2015

nodakai commented on Aug 2, 2015

rohel01 commented on Aug 14, 2015

glaebhoerl commented on Aug 15, 2015

aturon commented on Nov 5, 2015

briansmith commented on Jan 12, 2016

glaebhoerl commented on Jan 15, 2016

278 remaining items

SimonSapin commented on Jan 2, 2019

phansch commented on Jan 9, 2019

Centril commented on Jan 9, 2019

durka commented on Jan 9, 2019

ErichDonGubler commented on Jan 9, 2019

nixpulvis commented on Jan 9, 2019

nixpulvis commented on Jan 9, 2019

shepmaster commented on Jan 9, 2019

varkor commented on Jan 13, 2019

glaebhoerl commented on Jan 13, 2019

Centril commented on Jan 13, 2019

jtakalai commented on Mar 22, 2019

oli-obk commented on Mar 22, 2019

theoparis commented on Nov 30, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions