Individualize feature gates for const fn invocation

[durka]

This PR changes the meaning of #![feature(const_fn)] so it is only required to declare a const fn but not to call one. Based on discussion at #24111. I was hoping we could have an FCP here in order to move that conversation forward.

This sets the stage for future stabilization of the constness of several functions in the standard library (listed below), so could someone please tag the lang team for review.

• std::cell
  • Cell::new
  • RefCell::new
  • UnsafeCell::new
• std::mem
  • size_of
  • align_of
• std::ptr
  • null
  • null_mut
• std::sync
  • atomic
    • Atomic{Bool,Ptr,Isize,Usize}::new
  • once
    • Once::new
• primitives
  • {integer}::min_value
  • {integer}::max_value

Some other functions are const but they are also unstable or hidden, e.g. Unique::new so they don't have to be considered at this time.

After this stabilization, the following *_INIT constants in the standard library can be deprecated. I wasn't sure whether to include those deprecations in the current PR.

• std::sync
  • atomic
    • ATOMIC_{BOOL,ISIZE,USIZE}_INIT
  • once
    • ONCE_INIT

[rust-highfive]

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

[eddyb]

cc @rust-lang/lang

[sfackler]

WRT deprecations, we prefer to do those a release or two after.

[Mark-Simulacrum]

[00:51:26] error: use of unstable library feature 'sort_unstable' (see issue #40585)
[00:51:26]    --> /checkout/src/test/run-pass/vector-sort-panic-safe.rs:174:30
[00:51:26]     |
[00:51:26] 174 |                 test!(input, sort_unstable_by);
[00:51:26]     |                              ^^^^^^^^^^^^^^^^
[00:51:26]     |
[00:51:26]     = help: add #![feature(sort_unstable)] to the crate attributes to enable
[00:51:26] 
[00:51:26] error: use of unstable library feature 'sort_unstable' (see issue #40585)
[00:51:26]    --> /checkout/src/test/run-pass/vector-sort-panic-safe.rs:174:30
[00:51:26]     |
[00:51:26] 174 |                 test!(input, sort_unstable_by);
[00:51:26]     |                              ^^^^^^^^^^^^^^^^
[00:51:26]     |
[00:51:26]     = help: add #![feature(sort_unstable)] to the crate attributes to enable
[00:51:26] 
[00:51:26] error: aborting due to 2 previous errors

[durka]

Fixed botched rebase.

[withoutboats]

@rfcbot fcp merge

[SimonSapin]

After this stabilization, the following *_INIT constants in the standard library can be deprecated. I wasn't sure whether to include those deprecations in the current PR.

Do we have a mechanism yet to make something deprecated in some future version? (In this case 1.22+, I think.) It’s bothersome if Nightly warns and says to use instead something that is not available in the Stable channel yet.

[SimonSapin]

#42859 adds size_of and align_of to the list.

[rfcbot]

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

• @aturon
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix
• @withoutboats

Concerns:

• constness resolved by Individualize feature gates for const fn invocation #43017 (comment)

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.

[brson]

After this stabilization, the following *_INIT constants in the standard library can be deprecated. I wasn't sure whether to include those deprecations in the current PR.

No, please don't deprecate during the same release as the replacement. Give it a while.

[joshtriplett]

This is a bit of a tangent, but I'd assume this applies to core::mem::size_of and similar, not just std::mem::size_of?

[nikomatsakis]

@rfcbot concern constness

In discussion in the @rust-lang/lang meeting, the question was raised whether we want to have the ability to control whether to stabilize the "constness" of individual functions. So, for example, one might imagine making size_of and align_of usable in constants, but not necessarily every const fn (since some of them might rely on impl details that we are not sure if we will want to stabilize).

[joshtriplett]

@rust-lang/lang was generally in favor of making this change, and stabilizing size_of and align_of as const functions; the only concern was whether this might open the floodgates to stabilize numerous other library functions as const as well, and whether in adding all such functions, we might unnecessarily constrain ourselves in the development of const_fn. We'd recommend being very conservative about what in the standard library should be stabilized as const.

There was also some discussion about whether this automatically makes the constness of all const functions in the library immediately stable, which might not have been anticipated. There was discussion elsewhere about whether there might be future extensions of some such functions/traits that may be non-const.

[eddyb]

@joshtriplett std::mem is a mere reexport of core::mem so yes, they are the same functions.

[durka]

As written, yes, it stabilizes the constness of const fns in core/std. It seems rather useless to stabilize uses of const fn, but not declarations, and then not declare any const fns :) If we have to be hyper-conservative and start with just size_of/align_of, I guess that's OK, but I'm also excited to get rid of tons of lazy_statics which only exist in order to call Cell::new etc! I'm not 100% sure how we would implement stabilizable-constness. One approach that comes to mind is a build script for core and std that checks which train we are compiling, and sets a cfg flag. But then for a user if you *are* on nightly, there's no opt-in, you just get a const.

…

On Thu, Jul 6, 2017 at 3:45 PM, Eduard-Mihai Burtescu < ***@***.***> wrote: @joshtriplett <https://github.com/joshtriplett> std::mem is a mere reexport of core::mem so yes, they are the same functions. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#43017 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n9jAY5Oj_QqARZHnm7R08DiCciqWks5sLTllgaJpZM4OLrkp> .

[durka]

We could also just un-constify the rest of that list, breaking nightly users until we figure out which library functions can be const. Are there any specific concerns, though?

[nikomatsakis]

@durka

If we have to be hyper-conservative and start with just size_of/align_of, I guess that's OK, but I'm also excited to get rid of tons of lazy_statics which only exist in order to call Cell::new etc!

I have no problem being more aggressive than such a minimal starting set, but it seems like it'd be useful to have the ability to add things later that we don't stabilize immediately.

[nikomatsakis]

That said, perhaps un-constifying is indeed a viable alternative.

[durka]

All I can think of is adding a magic function attribute #[rustc_const_stable(since = "...")], and then basically undoing this PR :( but adding a check for the attribute here https://github.com/rust-lang/rust/pull/43017/files#diff-c2552a106550d05b69d5e07612f0f812L782

[bors]

📌 Commit 332c38c has been approved by eddyb

[bors]

⌛ Testing commit 332c38c with merge ae8efdc...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing ae8efdc to master...

[durka]

Thanks for bearing with me @kennytm and @eddyb (and @bors). Next up, figuring out which of these are actually uncontroversial to stabilize!

…

On Sep 16, 2017 15:55, "bors" ***@***.***> wrote: Merged #43017 <#43017>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#43017 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n6lgClFDCPpVSyAxgnNjIfGr1ev1ks5sjCepgaJpZM4OLrkp> .

[mystor]

@durka Did you ever open a bug to try to stabilize the uncontroversial const functions? It seemed from reading this that size_of and align_of, for example, are not controversial, yet I couldn't find a bug tracking their stabilization.

[durka]

I'll try to get that process started. I guess #24111 is still tracking all the const fns -- maybe that's too confusing.