add raw_ref macros

[RalfJung]

In #64490, various people were in favor of exposing &raw as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros.

I'll create the tracking issue if we're okay moving forward with this.

[rust-highfive]

r? @LukasKalbertodt

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

[ecstatic-morse]

This was discussed again in the @rust-lang/lang team meeting, and the general consensus in #64490 (comment) has not changed. The question of whether some form of rust-lang/rfcs#2919 before stabilizing these macros was briefly discussed but not conclusively answered.

AFAIK, all this needs is sign-off from T-libs on the precise syntax and the implementation.

[nikomatsakis]

@rfcbot fcp merge

Proposal

Introduce two macros

• raw_ref!(path)
• raw_ref_mut!(path)

which borrow the contents at path and produce (respectively) *const T and *mut T raw pointers.

Motivation for exposing these capabilities

Unlike the & syntax, no "safe reference" is created. This means that the resulting raw pointer can be misaligned
or invalid to dereference and that is not UB until the pointer is actually dereferenced. For more details see RFC 2582.

Motivation for using macro-based syntax

This is an alternative to the previous syntax specified in RFC 2582, which was &raw const and &raw mut.

The motivations for making this change is that the syntax &raw const and &raw mut is not seen as particularly ideal. Among its downsides:

• It is verbose and wordy.
• It introduces a fresh contextual keyword raw.
• It breaks the symmetry that we previously have had, where &foo creates a &T type (and &mut foo creates a &mut T) type.

Further, we think that there may be an opportunity to revisit raw-pointer ergonomics in a bigger way that could improve the language overall (some background available in these three messages, particularly the final one). We don't feel ready to decide if that opportunity is worth the resulting churn, but we don't feel the need to commit to syntax like &raw const that may become deprecated.

Future possibilities

The raw_ref and raw_ref_mut macros would be stable and hence usable in perpetuity. If we do wind up adopting a larger "raw pointer reform" than these macros might be deprecated in favor of the newer types and operators.

On the other hand, if we wind up deciding that larger "raw pointer reform" doesn't make sense, we might add some more "builtin" syntax than the raw_ref macros. Alternatively, we might simply keep the macros as they are, as they address a somewhat niche concern (creating raw pointers to invalid or unaligned memory, where the rules for a standard reference would be invalid).

[rfcbot]

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

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.

[Dylan-DPC-zz]

r? @cramertj

[nikomatsakis]

Nominating for next lang-team meeting to draw attention these checkboxes.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

@rfcbot reviewed

Definitely no concerns with this as unstable.

[mystor]

Due to the const provenance issues @Gankra mentioned in #64490 (comment), I would think that we'd want people to prefer using *mut over *const when they can, as it probably produces the expected behaviour wrt stacked borrows. If that's still the case, it seems a bit unfortunate that the proposed macro names make the mut variant less ergonomic to write then the const variant, encouraging the use of raw_ref! by default.

Perhaps raw_const_ref! and raw_mut_ref! (or raw_ref_const!/raw_ref_mut!) would be better names?

[brain0]

Perhaps raw_const_ref! and raw_mut_ref! (or raw_ref_const!/raw_ref_mut!) would be better names?

The usual Rust naming convention would be raw_ref! and raw_mut! (same as the as_raw() and as_mut() methods).

Another alternative would be raw_const! and raw_mut! to be consistent with *const and *mut. Since the result is not actually a reference, but a raw pointer, I would personally prefer this syntax.

[RalfJung]

I can change the name to anything as long as there's consensus. :) Don't really care myself.

[withoutboats]

maybe even raw_const_ptr / raw_mut_ptr. These are exposed from the root of std, right?

[RalfJung]

These are exposed from the root of std, right?

Yes, but I can also make them "macro 2.0" macros and put them into some module -- I was not sure if that is already acceptable to do.

[nikomatsakis]

I don't have a strong opinion about the names we use, and I would love @rust-lang/libs feedback on the best way to expose them. I think something like std::ptr::raw!(...) or something might be nice, if we are doing that.

[sfackler]

I'd definitely prefer to have them be located in ptr rather than the crate root personally.

[withoutboats]

I think having them available only at the paths std::ptr::raw_const and std::ptr::raw_mut would be ideal, but I think this is the first time std would expose macros that way, and I'm not sure what the bigger picture of doing that is (does it work in 2015 edition / do we care? are we comfortable starting to do this with std macros in general? etc)

[nikomatsakis]

@bors r+

[bors]

📌 Commit 0265e4e has been approved by nikomatsakis