const fn tracking issue (RFC 911)

[nikomatsakis]

#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

[Munksgaard]

Is this closed by #25609?

[abonander]

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

[nodakai]

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 _

[rohel01]

EDIT: Removed since it was out of subject

[glaebhoerl]

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.