Stabilize raw ref macros

[RalfJung]

This stabilizes raw_ref_macros (#73394), which is possible now that #74355 is fixed.

However, as I already said in #73394 (comment), I am not particularly happy with the current names of the macros. So I propose we also change them, which means I am proposing to stabilize the following in core::ptr:

pub macro const_addr_of($e:expr) {
    &raw const $e
}

pub macro mut_addr_of($e:expr) {
    &raw mut $e
}

The macro name change means we need another round of FCP. Cc @rust-lang/libs
Fixes #73394

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[mark-i-m]

const_raw_ref and mut_raw_ref?

raw_ref and mut_raw_ref?

[RalfJung]

@mark-i-m I don't think "raw references" are a term I've ever seen.

[danielhenrymantilla]

I like the new names in this PR better; although using addr is slightly suboptimal (pointers are not (just) addresses yadda yadda), but besides that pedantic nit I think "addr of" conveys the meaning of C's & / Rust's &raw operator better than speaking of (raw) ref-erences.

Also, tiny nit: could $e be renamed to $place? Since giving a non-place expression yields an error (which is great btw! Having potentially immediately dangling pointers would have been a bit of a footgun, so props on the compilation error).

[tesuji]

I don't think "raw references" are a term I've ever seen.

Maybe a misunderstand from the feature name: raw_ref_macros ?

[RalfJung]

Also, tiny nit: could $e be renamed to $place? Since giving a non-place expression yields an error

Sure, done.

[danielhenrymantilla]

giving a non-place expression yields an error

Should there be a UI test for this?

[RalfJung]

The error comes from the underlying &raw, I don't think it makes sense to duplicate the test for the macro.
src/test/ui/raw-ref-op/raw-ref-temp.rs tests the underlying &raw.

[mark-i-m]

@mark-i-m I don't think "raw references" are a term I've ever seen.

@RalfJung Sorry, I'm forgetting what *const T and *mut T are called. Raw pointers? Would const_raw_ptr and mut_raw_ptr be better?

[RalfJung]

Yeah I think "raw pointers" is the usual term, sometimes just "pointers".

The macros are in the ptr namespace, so ptr::const_raw_ptr seems a bit redundant? const_raw on the other hand is hard to decipher, not much better than the current raw_const!. Also, const_raw_ptr!((*x).some_field) is IMO less clear than "address of".

But const_raw_ptr! is definitely better than the current raw_const!. So it would be an okay fallback for me if const_addr_of! doesn't find consensus.

[danielhenrymantilla]

unsafe // Safety: keep it cool :)
fn bikeshed (x: *mut SomeStruct)
{
    use ::core::ptr;

    ptr::raw_const!((*x).some_field);
    ptr::raw_mut!((*x).some_field);

    ptr::const_addr_of!((*x).some_field);
    ptr::mut_addr_of!((*x).some_field);

    // Personal modification of the `{const,mut}_raw_ptr!` suggestion
    ptr::const_ptr_to!((*x).some_field);
    ptr::mut_ptr_to!((*x).some_field);

    // Another personal suggestion
    ptr::raw_ptr!(&raw const (*x).some_field);
    ptr::raw_ptr!(&raw mut (*x).some_field);

    use ::core::ptr::*;

    raw_const!((*x).some_field);
    raw_mut!((*x).some_field);

    const_addr_of!((*x).some_field);
    mut_addr_of!((*x).some_field);

    const_ptr_to!((*x).some_field);
    mut_ptr_to!((*x).some_field);

    raw_ptr!(&raw const (*x).some_field);
    raw_ptr!(&raw mut (*x).some_field);
}

My personal stance (fwiw)

I don't have a strong preference here, except for raw_{const,mut} being the pair that reads the worst. When looking at this, const_addr has the drawback of not necessarily leading to the same muscle memory as const_ptr does, so I think I prefer ptr_to to addr_of for this reason. Finally, the idea of having not two but one macro could be worth exploring 🤷

[RalfJung]

const_ptr_to/mut_ptr_to looks like a reasonable alternative to addr_of.

I don't think we want raw_ptr!(&raw const (*x).some_field); the entire point of this is to not stabilize the &raw syntax.

[mark-i-m]

@RalfJung We could have it be "generic" though: ptr_to(const (*x).some_field) and ptr_to(mut (*x).some_field)...

[m-ou-se]

Since this is tagged as I-nominated we'll discuss this in the libs meeting next week. But here's some first thoughts:

The names const_addr_of and mut_addr_of make it sound like const and mut apply to the address.

The name const_addr_of makes me think more of const X: T = ..;, const fn and compile time evaluation rather than of the opposite of mut, especially since most const+mut pairs in Rust are called thing+thing_mut instead of thing_const+thing_mut. (I do realise this is specifically not the case for *const T+*mut T, but still.)

Do you have any alternatives for the names in mind? What would you think of something like addr_of and addr_of_mut?

[RalfJung]

The name const_addr_of makes me think more of const X: T = ..;, const fn and compile time evaluation rather than of the opposite of mut

Yeah, I know. This is even worse with ptr::raw_const!, which is the current name. The new name at least indicates more clearly that const is an adjective. That's why I think the new names make this confusion less likely, but they certainly do not alleviate it.

especially since most const+mut pairs in Rust are called thing+thing_mut instead of thing_const+thing_mut. (I do realise this is specifically not the case for *const T+*mut T, but still.)

Indeed, we have & and &mut -- but not for raw pointers.

Do you have any alternatives for the names in mind? What would you think of something like addr_of and addr_of_mut?

Some thoughts:

• I feel it would be strange to deviate from the *const/*mut names of the types that are being constructed here.
• addr_of_mut sounds like it is taking the address of something mutable, which is IMO the wrong picture -- the right picture is that this takes the address and stores it in a *mut.
• Mutability in raw pointers is mostly meaningless / "just a lint", but it might still matter sometimes (Coercing &mut to *const should not create a shared reference #56604). So when people want to do mutation I'd still advise against using const_addr_of, so making the const version have the shorter (-> more ergonomic) name (addr_of) is not a good call, in my opinion.

I feel like all choices are bad here, and I had hoped that the libs team would have some good ideas since they certainly have more experience naming Rust APIs than I do. :)

[m-ou-se]

I feel it would be strange to deviate from the *const/*mut names of the types that are being constructed here.

We already do that for ptr::null+ptr::null_mut and ptr::slice_from_raw_parts+ptr::slice_from_raw_parts_mut though.

addr_of_mut sounds like it is taking the address of something mutable, which is IMO the wrong picture

Even though const/mut in pointers is mostly meaningless, isn't *mut T is still supposed to point to a mutable T?

the right picture is that this takes the address and stores it in a *mut.

How would you pronounce *mut T? "mut pointer"? "pointer to mut"? Or something else?

[RalfJung]

Even though const/mut in pointers is mostly meaningless, isn't *mut T is still supposed to point to a mutable T?

I guess it is, but personally on the few occasions that I have been writing raw pointer code, that's not how I thought about this. But maybe I am thinking about this in weird ways.

How would you pronounce *mut T? "mut pointer"? "pointer to mut"? Or something else?

I'd say "mutable raw pointer", and "const(ant) raw pointer" for *const T.

[RalfJung]

All right, I renamed the macros accordingly. I left the version at 1.51, hoping this will land until the next beta branches on Monday. :D

EDIT: Oh, it's Monday the week after the next. No rush then.^^

[m-ou-se]

FCP with the old names (raw_const, raw_mut) happened here: #73394 (comment).

The new names are the result of a meeting which was attended by five libs team members.

So, no need for a new FCP, as the names are just a small change.

@bors r+

[bors]

📌 Commit 13ffa43 has been approved by m-ou-se