Tracking issue for RFC 2582, &raw [mut | const] $place (raw_ref_op)

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#1567
Stabilization 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

I'll try to get a PR open for this soon.

@matthewjasper

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.

...but it seems @matthewjasper already has a PR heh.

Make safe_packed_borrows a hard error when the feature gate is active, and make this the case as well for unsafe equivalents.

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.

I wonder why not &raw $expr but &raw const $expr. Is there a discussion about this?

@moshg

@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.

The RFC thread noted a couple times (including in the FCP comment) that &raw expr without the const 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.

@mjbshaw

@mjbshaw @lxrec
Thank you for your explanations! I've understood why &raw $expr is breaking change.

I think it might be worth amending the RFC to state why &raw const $expr was chosen over &raw $expr.

rust-lang/rfcs#2764

@RalfJung

@RalfJung I'm addressing the points you've made in rust-lang/rfcs#2582 (comment)

promotion being confusing here seems mostly orthogonal to raw-vs-ref, doesn't it?

While it would be helpful to have at least a warning for a promotion in &mut <rvalue> case, disabling it is a backward incompatible change to the language. In &raw mut <rvalue> case it can be done from the beginning.

If no promotion happens with raw ptrs, what would you expect to happen instead?

I would expect &raw mut <rvalue> to result in compilation error, as &<rvalue> does in C.

I would expect &raw mut (1+2) to be promoted the same way &mut (1+2) is; not doing that seems even more confusing and very error-prone

I have an impression that silently allowing such promotions is more error prone, as it violates the principle of least surprise.

trait AddTwo {
    fn add_two(&mut self);
}

impl AddTwo for u32 {
    fn add_two(&mut self) { *self += 2; }
}

const N: u32 = 0;
// somewhere else
assert_eq!(N, 0);
// N += 2; // doesn't compile
N.add_two(); // compiles with no warnings
assert_eq!(N, 2); // fails

promotion being confusing here seems mostly orthogonal to raw-vs-ref, doesn't it?

yes, promotion has nothing to do with it as far as I can tell.

I would expect &raw mut to result in compilation error, as & does in C.

I agree. We should error on any &raw place where place

has no Deref projections (*) or Index ([i]) projections
and has a temporary local as base

since we still want to permit &raw *foo() I would assume. Or more concretely &raw foo().bar when foo() returns a reference.

If "erroring if not" has too many negations (i confused myself in the process of writing this), here's a version of what I think we should permit (and only that):

We should permit &raw place only if place

has Deref projections or Index projections
or has a static or local variable as the base

@Gankra

It's also my recollection that there were no blocking concerns on the grammar or parsing side.

There were three questions I recall without a definitive answer:

&raw $place versus &raw const $place, and whether the syntax should be evoking *const T or &T.
- From a grammar side, &raw (expr) still requires making raw a contextual keyword here. But the question is whether const is just a concession to parsing that we'd prefer to remove, or if it's desirable as evocative of *const T.
&raw const $place giving a read-only pointer even when used on a writable place is contentious.
It's unclear what &raw const (*ptr).field requires from ptr — is it gepi or gep, and the related generality/optimization toggles.
- The problem here is that dereferencing into "place mode" is potentially the wrong abstraction.

Additionally, there is one big "shiny future" possibility: &raw const T (or just &raw T, or &'unsafe T, or any other number of possibilities) for a "better raw pointer" type. The problems and footguns with working with the existing *[const|mut] T and ptr::NonNull<T> are well documented and I won't rehash them here. If in a shiny future we get a built-in nicer raw pointer type, &raw [const|mut] T is currently the most promising syntax for creating a raw pointer (and that's why it's used here), and it'd be a shame to have worse syntax for the better thing, and better syntax for the worse thing.

(But seriously, go read every single thing @Gankra has written about pointers.)

To be clear: I'm not arguing we shouldn't improve what we have because we might be able to do it better in the future. Rather, there are existing proposals that show we really should consider

If we had a time machine, what would we want Rust pointers to look like?

and how close can we realistically get to that ideal?

I think we can get close enough that Rust is a contender for the best language to write C in. This isn't the case currently because of how easy it is to incidentally introduce reference semantics into pointer code (along with other papercuts), but I have faith that we can make it there.

So I guess the conclusion of this is: &raw hasn't stabilized yet because while it is agreeably the best implementation of this solution to this problem, we're still not necessarily in agreement that this is the correct problem to be solving.

Given a magical grant of bandwidth, this is what I personally think should be the path forward:

Collect a T-lang design notes document for "pointer pain points"
From the pain points, T-lang decides on which path we want to pursue: new pointer type(s) or old pointer types
If old pointer types:
- Stabilize &raw $place syntax 🎉
If new pointer type(s)
- If &raw T:
  - &raw $place makes them and not * [const|mut] T
- If a new keyword/sigil/etc:
  - Too much of an unknown to predict
- If a named type (e.g. ptr::NonNull<T>)
  - Determine if place-to-new-pointer is an important operation that wants the & {?} $place syntax space
  - If not: stabilize &raw $place syntax to make today's Rust significantly better 🎉

(And to try to predict the future: I predict that a far-future pointer-perfect Rust has refinement typing for pointers and that ptr::NonNull and ptr::WellFormed are aliases for the namable refined pointer types that can cross function boundaries. Prefix deref is deprecated in favor of .read()/.write()/.as_ref()/.as_mut() and . for safe field offsetting, ~ for unsafe GEPi field offsetting. container_of! is still, as usual, a controversial nightmare.)

Update Rust crate syn to v2 (#396)

fix(deps): update rust crate syn to v2 (#2512)

Collect a T-lang design notes document for "pointer pain points"

From the pain points, T-lang decides on which path we want to pursue: new pointer type(s) or old pointer types

Seems like we are still at this stage. So if someone wants to push this forward, working on such a document would be the best way to help. :)

On the other hand, if we are getting a better raw pointer type in the future, we always have the option of using an edition transition to change the meaning of &raw. So maybe we should just stabilize what we got so that we can finally stop using a macro for this?

Stabilization of this feature is in FCP over at #127679. :)

Auto merge of rust-lang#127679 - RalfJung:raw_ref_op, r=<try>

Rollup merge of rust-lang#127679 - RalfJung:raw_ref_op, r=traviscross…

Rollup merge of rust-lang#127679 - RalfJung:raw_ref_op, r=jieyouxu

Unrolled build for rust-lang#127679

Rollup merge of #127679 - RalfJung:raw_ref_op, r=jieyouxu

Navigation Menu

Repository navigation

Tracking issue for RFC 2582, `&raw [mut | const] $place` (raw_ref_op) #64490

83 remaining items

If we had a time machine, what would we want Rust pointers to look like?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for RFC 2582, &raw [mut | const] $place (raw_ref_op) #64490

Description

Activity

matthewjasper commented on Sep 15, 2019

Centril commented on Sep 15, 2019

Aaron1011 commented on Sep 15, 2019

moshg commented on Sep 15, 2019

mjbshaw commented on Sep 15, 2019

Ixrec commented on Sep 15, 2019

moshg commented on Sep 16, 2019

RalfJung commented on Sep 16, 2019

red75prime commented on Oct 9, 2019

oli-obk commented on Oct 9, 2019

83 remaining items

CAD97 commented on Jun 23, 2022

If we had a time machine, what would we want Rust pointers to look like?

RalfJung commented on Mar 16, 2024

RalfJung commented on Mar 17, 2024

RalfJung commented on Aug 15, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for RFC 2582, `&raw [mut | const] $place` (raw_ref_op) #64490