Make ptr::from_raw_parts more general

[scottmcm]

Proposal

Problem statement

Today, ptr::from_raw_parts can only accept *const () for the data_pointer.

That means that common cases -- like making a slice pointer -- have to cast.

Motivating examples or use cases

ptr::slice_from_raw_parts exists primarily so that something could be stabilized, but it's also there because if you're making a *const [T] what you really want to provide is a *const T and a usize, not a *const () and a usize.

There's really no reason, though, that ptr::from_raw_parts couldn't just take the *const T directly.

Solution sketch

Make a couple small tweaks to the signatures:

 pub const fn from_raw_parts<T: ?Sized>(
-    data_pointer: *const (),
+    data_pointer: *const impl Thin,
     metadata: <T as Pointee>::Metadata,
 ) -> *const T { … }

 pub const fn from_raw_parts_mut<T: ?Sized>(
-    data_pointer: *mut (),
+    data_pointer: *mut impl Thin,
     metadata: <T as Pointee>::Metadata,
 ) -> *mut T { … }

etc.

That way you still can't pass a fat pointer as the data_pointer, but if you happen to have a *mut u8 from an allocator, or something, that's fine.

And the turbo-fishing still lets you do from_raw_parts::<[T]> or from_raw_parts::<dyn Foo> without needing an extra _.

Alternatives

Obviously doing nothing here is a feasible option. It's not like casting is difficult.

But like with byte_offset_from (see rust-lang/rust#103489 ), there's really no particular reason to force a specific type here, and it's handy to accept multiple.

Links and related work

Inspired by rust-lang/rust#123190 since the extra casts were pushing Vec::deref over the MIR inlining threshold, but the cast to *const () also wasn't providing any value, so it would be nice to just not make people write it at all.

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[scottmcm]

Nominating because it seems like it fell off the "new ACPs" agenda without comment. It's not urgent, though; address it only after any more-pressing nominees.

@rustbot labels +I-libs-api-nominated

[the8472]

Ideally we'd do better with something like *const Thin<T> or whatever so it still carries the type. But I think we don't have a way to name a thin-pointer-equivalent to something that needs metadata

[scottmcm]

Interesting, @the8472 . I think that'd be particularly useful for to_raw_parts, since today it just shrugs and gives everyone a pointer-to-unit.

For constructing, I do wonder about things like the "flat vector of dyn", where it might in practice have *const u8s anyway, so from_raw_parts::<dyn Foo>(p, vtable) might still be preferable to p.cast::<Thin<dyn Foo>>().with_meta(vtable).

I guess we could always experiment with a Thin that's just a newtype on an opaque type and see how it goes? I'll still make this change to from_raw_parts in the mean time, since it sounds like it was approved today and it might save a case in hypothetical Thin::with_meta implementation anyway.

TL/DR: from_raw_parts is still unstable, so we can always change it again in a future ACP 🙂

[Amanieu]

We discussed this in the libs-api meeting today and we're mostly happy to accept it. We can defer the final decision to stabilization since this depends on several unstable features (e.g. trait aliases for Thin).