Github Stabilize raw ref macros by RalfJung · Pull Request #80886 · rust-lang/ru... - JOYK Joy of Geek, Geek News, Link all geek

Member

RalfJung commented on Jan 11

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

Collaborator

rust-highfive commented on Jan 11

r? @m-ou-se

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

This comment has been hidden.

Member

mark-i-m commented on Jan 11

const_raw_ref and mut_raw_ref?

raw_ref and mut_raw_ref?

RalfJung

force-pushed the

RalfJung:stable-raw-ref-macros

branch from 6854bf5 to 215f96e

on Jan 11

Member

Author

RalfJung commented on Jan 11

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

Contributor

danielhenrymantilla commented on Jan 11

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

Contributor

tesuji commented on Jan 11

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

Maybe a misunderstand from the feature name: raw_ref_macros ?

Member

Author

RalfJung commented on Jan 11

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

Sure, done.

Contributor

danielhenrymantilla commented on Jan 11

giving a non-place expression yields an error

Should there be a UI test for this?

Member

Author

RalfJung commented on Jan 11

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.

Member

mark-i-m commented on Jan 12

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

Member

Author

RalfJung commented on Jan 12

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.

Contributor

danielhenrymantilla commented on Jan 12

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)

Member

Author

RalfJung commented on Jan 12

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.

Member

mark-i-m commented on Jan 12

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

This comment has been hidden.

RalfJung

force-pushed the

RalfJung:stable-raw-ref-macros

branch from d57bc9b to 3d93784

on Jan 14

Member

m-ou-se commented on Jan 14

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?

Member

Author

RalfJung commented on Jan 14 •

edited

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 (#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. :)

Member

m-ou-se commented on Jan 14

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?

Member

Author

RalfJung commented on Jan 14

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.