Tracking Issue for ptr_from_ref

[RalfJung]

Feature gate: #![feature(ptr_from_ref)]

This is a tracking issue for ptr::from_{ref,mut}: methods to turn references into raw pointers without using as casts. We have methods to avoid almost all as casts around raw pointer handling, except for the initial cast from reference to raw pointer. These new methods close that gap. They also ensure that the pointee type T remains the same, without one having to repeat that type for the cast.

Public API

pub fn from_ref<T: ?Sized>(r: &T) -> *const T;
pub fn from_mut<T: ?Sized>(r: &mut T) -> *mut T;

Steps / History

• Implementation: add ptr::from_{ref,mut} #104977
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[SoniEx2]

for context of where these may be relevant, see also the discussion in rust-lang/book#3305

[SUPERCILEX]

Filed an issue for a clippy lint: rust-lang/rust-clippy#10130

[scottmcm]

Pondering based on https://users.rust-lang.org/t/best-way-to-cast-option-t-to-const-t/88402?u=scottmcm: Should this perhaps take Option<&T>?

There's NonNull::from that takes &T...

[SUPERCILEX]

Is there a way to make it accept an Into<Option<&T>>? Otherwise I feel like that will make these methods unpleasant to use in most cases.

[QuineDot]

You would need a way to create wide null pointers to convert from a generic Option<&T>. core::ptr::null doesn't do that yet, and due to RFC 3324 a valid vtable will be required for dyn pointers.

Probably that's desired functionality for null() anyway, but I'm not sure how it could be done in the wider context of custom DSTs. Perhaps

pub const fn null<T>() -> *const T
where
    T: Pointee + ?Sized,
    <T as Pointee>::Metadata: MetadataForNull,

for some sealed trait the compiler automatically implements for all DynMetadata<dyn Trait> (and an implementation for (), and maybe usize).

Or a new public trait Null that the compiler automatically implements for all dyn Trait (with corresponding blanket implementations for T: Thin).

Alternatively, the safety invariant for *const dyn Trait could be relaxed when the data pointer is Null I guess. Whatever upcasting does under the hood would have to check for Null.

[RalfJung]

Pondering based on https://users.rust-lang.org/t/best-way-to-cast-option-t-to-const-t/88402?u=scottmcm: Should this perhaps take Option<&T>?

I usually think that having as_ref return an Option is a mistake, so this seems to be like just making the symmetric mistake here. It would be consistent, but I'd rather us find a way to have a version of as_ref that returns &T.

I think methods that treat null specially should be working on Option<NonNull<T>>, not *mut T.

[Raekye]

It seems to me that these functions could trivially be made const. Is there a reason they're not/what would it take to have them changed, since they're not stable yet?

[scottmcm]

@Raekye Seems entirely reasonable; send a PR!

[scottmcm]

Pondering: &mut T → *const T will compile with both from_ref or from_mut, given that there are coercions available on both sides.

Is there anything that we should do with these to help people from accidentally using from_ref when they should have used from_mut to keep the permission to cast back to *mut and mutate later?

That seems like the kind of mistake that you could make but not notice for a long time if you're just running normal binaries rather than MIRI.

[RalfJung]

We could have a lint for that situation (any time a mutable ref is passed to from_ref, basically).

[WaffleLapkin]

What's the status here? Is this just waiting for someone to start stabilization process? Do we need more lints? Is something else missing?

[RalfJung]

Is this just waiting for someone to start stabilization process?

I think that.
Though having a lint, at least in clippy, is nice -- I don't think it is blocking.

[jhpratt]

As #117824 has been merged, this should be closed.