Remove restriction on dereferencing pointers in const #2090
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
the
S-waiting-on-review
traviscross
force-pushed
the
TC/remove-restriction-on-dereferencing-pointers-in-const
branch
from
8c89538 to
3dab34b
Compare
We had said that the dereference operator could not be used with raw pointers in a constant expression. However, that restriction has been lifted. First, in Rust 1.58, we stabilized `const_raw_ptr_deref`. rust-lang/rust#89551 This allowed for dereferencing immutable raw pointers in a constant expression. Then, in Rust 1.83, we stabilized `const_mut_refs` and `const_refs_to_cell`. rust-lang/rust#129195 That allowed for: - Mentioning `&mut` types. - Creating `&mut` and `*mut` values. - Creating `&T` and `*const T` values where `T` contains interior mutability. - Dereferencing `&mut` and `*mut` values (both for reads and writes). Let's remove the stated restriction on dereferencing raw pointers in a constant expression and add examples.
To define what's allowed in a constant expression, we have a list that starts with the text: > The following expressions are constant expressions... Correspondingly, most of the items in this list are stated in terms of being a "this expression" or a "that expression". However, for deref, we had instead said "the dereference operator". Even though the `expr.deref` section is currently titled "the dereference operator", it seems more clear and consistent in the context of this list to talk about dereference expressions, so let's do that. These are expressions, after all, The grammar production is named `DereferenceExpression`. (There is one other place in the list that we talk about operators: "built-in negation, arithmetic, logical, comparison, or lazy boolean operators used on integer and floating point types, `bool`, and `char`." Perhaps we'll reword that one later. It stands out a bit less than this one did.)
traviscross
force-pushed
the
TC/remove-restriction-on-dereferencing-pointers-in-const
branch
from
3dab34b to
71865f1
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We had said that the dereference operator could not be used with raw pointers in a constant expression. However, that restriction has been lifted. First, in Rust 1.58, we stabilized
const_raw_ptr_deref.rust-lang/rust#89551
This allowed for dereferencing immutable raw pointers in a constant expression. Then, in Rust 1.83, we stabilized
const_mut_refsandconst_refs_to_cell.rust-lang/rust#129195
That allowed for:
&muttypes.&mutand*mutvalues.&Tand*const Tvalues whereTcontains interior mutability.&mutand*mutvalues (both for reads and writes).Let's remove the stated restriction on dereferencing raw pointers in a constant expression and add examples.
cc @ehuss @RalfJung
I noticed this when double-checking that we didn't need to do anything for:
cc @rust-lang/fls