Skip to content

Stabilizing const functions #311

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
May 23, 2020
Merged

Stabilizing const functions #311

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
61914b2
Stabilizing const functions
KodrAus Feb 26, 2020
8a7c773
Update maintaining-std.md
KodrAus Feb 26, 2020
43210f5
update const docs
KodrAus May 23, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions src/libs/maintaining-std.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -197,10 +197,6 @@ Changes to hot code might impact performance in consumers, for better or for wor

PRs shouldn’t have merge commits in them. If they become out of date with `master` then they need to be rebased.

### Are functions const-stabilized or constified?

Please CC `@rust-lang/wg-const-eval`.

## Merging PRs

PRs to [`rust-lang/rust`] aren’t merged manually using GitHub’s UI or by pushing remote branches. Everything goes through [`bors`].
Expand All @@ -227,8 +223,17 @@ Features can be stabilized in a PR that replaces `#[unstable]` attributes with `

You can find the right version to use in the `#[stable]` attribute by checking the [Forge].

### When a `const` function is being stabilized

Const functions can be stabilized in a PR that replaces `#[rustc_const_unstable]` attributes with `#[rustc_const_stable]` ones. The [Constant Evaluation WG] should be pinged for input on whether or not the `const`-ness is something we want to commit to. If it is an intrinsic being exposed that is const-stabilized then `@rust-lang/lang` should also be included in the FCP.

Check whether the function internally depends on other unstable `const` functions through `#[allow_internal_unstable]` attributes and consider how the function could be implemented if its internally unstable calls were removed. See the _Stability attributes_ page for more details on `#[allow_internal_unstable]`.

Where `unsafe` and `const` is involved, e.g., for operations which are "unconst", that the const safety argument for the usage also be documented. That is, a `const fn` has additional determinism (e.g. run-time/compile-time results must correspond and the function's output only depends on its inputs...) restrictions that must be preserved, and those should be argued when `unsafe` is used.

[API Guidelines]: https://rust-lang.github.io/api-guidelines
[Unsafe Code Guidelines WG]: https://github.com/rust-lang/unsafe-code-guidelines
[Constant Evaluation WG]: https://github.com/rust-lang/const-eval
[`rust-lang/rust`]: https://github.com/rust-lang/rust
[`rust-lang/rfcs`]: https://github.com/rust-lang/rfcs
[`rust-lang/rust-forge`]: https://github.com/rust-lang/rust-forge
Expand Down