Description
This is a tracking issue for the RFC "an operator to take a raw reference" (rust-lang/rfcs#2582), feature(raw_ref_op).
Steps:
- Implement the RFC (see this comment for a detailed checklist)Adjust documentation (see instructions on rustc-guide): operator expressions: add &raw reference#1567Stabilization PR (see instructions on rustc-guide): Stabilize
raw_ref_op
(RFC 2582) #127679
Unresolved questions:
(None left here, since the lint was moved to #127724)
Implementation history:
- Initial implementation: Add a raw "address of" operator #64588
Metadata
Metadata
Assignees
Labels
Blocker: Approved by a merged RFC but not yet implemented.Category: An issue tracking the progress of sth. like the implementation of an RFC`#![feature(raw_ref_op)]`Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation.Relevant to the language teamThis issue requires a nightly compiler in some way.
Activity
matthewjasper commentedon Sep 15, 2019
I'll try to get a PR open for this soon.
Centril commentedon Sep 15, 2019
I would suggest splitting the implementation work up into phases to make each part thoroughly reviewed and tested. However, think of this list as a bunch of tasks that need to be done at some point.
&raw [mut | const] $expr
in the parser and AST.unused_parens
lint works alright.safe_packed_borrows
a hard error when the feature gate is active, and make this the case as well forunsafe
equivalents....but it seems @matthewjasper already has a PR heh.
Aaron1011 commentedon Sep 15, 2019
I'm not sure that this is a good idea. This would make it impossible to gradually migrate a codebase over to using raw references - once the feature gate is enabled, all references to packed structs must be fixed at once in order to get the crate building again.
moshg commentedon Sep 15, 2019
I wonder why not
&raw $expr
but&raw const $expr
. Is there a discussion about this?mjbshaw commentedon Sep 15, 2019
@moshg Yes, this was discussed. See here (and the following comments) for an initial discussion. And here (and the following comments) for a signoff from grammar-wg. And here for an example that
&raw (expr)
can be ambiguous.I think it might be worth amending the RFC to state why
&raw const $expr
was chosen over&raw $expr
.Ixrec commentedon Sep 15, 2019
The RFC thread noted a couple times (including in the FCP comment) that
&raw expr
without theconst
conflicts with existing syntax and would break real code. rust-lang/rfcs#2582 (comment) goes into some detail. My understanding is that it is still possible to migrate to&raw expr
with breaking changes in an edition, and I didn't see much explicit discussion of that, but I think everyone agrees that there's enough urgency here that we definitely prefer making&raw const expr
a thing over blocking any solution on waiting for another edition.moshg commentedon Sep 16, 2019
@mjbshaw @lxrec
Thank you for your explanations! I've understood why
&raw $expr
is breaking change.RalfJung commentedon Sep 16, 2019
rust-lang/rfcs#2764
131 remaining items