Tracking issue for calling standard library const fns

[SimonSapin]

The functions below in the standard library are const fn with individual feature gates for calling them in constant expressions. This issue is tracking the stabilization of such calls.

CC #24111, the super-set feature which also includes defining new const fn items.

• std::sync::Once::new
• core::cell::Cell::new
• core::cell::RefCell::new
• core::cell::UnsafeCell::new
• core::sync::AtomicBool::new
• core::sync::AtomicPtr::new
• core::sync::Atomic$IntegerType::new
• core::mem::size_of
• core::mem::align_of
• core::ptr::null
• core::ptr::null_mut
• <$IntegerType>::max_value
• <$IntegerType>::min_value

Items in core:: are also re-exported in std::.

[SimonSapin]

Feature gates are:

• const_once_new
• const_cell_new
• const_refcell_new
• const_unsafe_cell_new
• const_size_of
• const_align_of
• const_ptr_null
• const_ptr_null_mut
• const_min_value
• const_max_value
• const_atomic_bool_new
• const_atomic_ptr_new
• const_atomic_i8_new
• const_atomic_u8_new
• const_atomic_i16_new
• const_atomic_u16_new
• const_atomic_i32_new
• const_atomic_u32_new
• const_atomic_i64_new
• const_atomic_u64_new
• const_atomic_isize_new
• const_atomic_usize_new

[aturon]

Kicking off stabilization discussion for the const-ness of these functions in std.

@rfcbot fcp merge

[rfcbot]

Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams:

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[chabapok]

How to about mark std::time::Duration::{from_millis, new, from_secs, from_micros} as const_fn?

[sfackler]

new can panic so it can't be const.

[durka]

@sfackler sure it can, the same way an indexing expression can be const (panic turns into const evaluation error).

[sfackler]

@durka How?

#![feature(const_fn)]

const fn foo(a: i32) {
    if a > 10 {
        panic!();
    }
}

fn main() {}

error[E0019]: constant function contains unimplemented expression type
 --> src/main.rs:4:5
  |
4 | /     if a > 10 {
5 | |         panic!();
6 | |     }
  | |_____^

error: aborting due to previous error

#![feature(const_fn)]

const fn foo(a: i32) {
    panic!();
}

fn main() {}

error[E0015]: calls in constant functions are limited to constant functions, struct and enum constructors
 --> src/main.rs:4:5
  |
4 |     panic!();
  |     ^^^^^^^^^
  |
  = note: this error originates in a macro outside of the current crate

error: aborting due to previous error

[eddyb]

I think this is "what is allowed right now" vs "what we could allow" (i.e. miri evaluates panics just fine).

[durka]

Yeah sorry, I just meant that *in theory* we could translate panics to compile errors.

…

On Nov 17, 2017 7:37 PM, "Eduard-Mihai Burtescu" ***@***.***> wrote: I think this is "what is allowed right now" vs "what we could allow" (i.e. miri evaluates panics just fine). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#46038 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n43M19qfGrHiLnHUOfS_2uTSttq9ks5s3ibbgaJpZM4QgrK5> .

[SimonSapin]

There are many more fns that could be made const once miri lands, and we should definitely consider them then. This issue is specifically about those that are already const, and stabilizing calls to them Very Soon^®.

[rfcbot]

The final comment period is now complete.

[SimonSapin]

I’ve submitted #46287