Repository navigation
Tracking Issue for [*const T|*mut T]::with_metadata_of #75091
Description
Feature gate: #![feature(set_ptr_value)]
Public API
impl<T: ?Sized> *mut T {
pub fn with_metadata_of<U: ?Sized>(self, val: *const U) -> *mut U;
}
impl<T: ?Sized> *const T {
pub fn with_metadata_of<U: ?Sized>(self, val: *const U) -> *const U;
}Steps / History
- Implementation: adds [*mut|*const] ptr::set_ptr_value #74774
- Change type and add
#[must_use]: Requested changes to [*mut T|*const T]::set_ptr_value #75407 - Reverse argument order and rename to
with_metadata_of: Refactor set_ptr_value as with_metadata_of #95249 - Const argument for mutable with_metadata_of: Adjust argument type for mutable with_metadata_of (#75091) #103346
- Final commenting period (FCP)
- Stabilization PR
Unresolved Questions
- Correct argument type --
*mut ()?*mut u8?*mut Opaque? - Is this even needed/useful given that there now also is Tracking Issue for pointer metadata APIs #81513?
Activity
Rollup merge of rust-lang#75407 - oliver-giersch:set_ptr_value, r=Ral…
SimonSapin commentedon Apr 16, 2021
As discussed on Zulip this could be replaced with
ptr::from_raw_parts(val, ptr::metadata(self)), tracked in #81513ChayimFriedman2 commentedon Mar 29, 2022
Even if we want to keep these methods I think it's better to write them in terms of the metadata API as it's easy to reason about and less error prone than the current implementation.
Argument type for mutable with_metadata_of (rust-lang#75091)
[-]Tracking Issue for [*const T|*mut T]::set_ptr_value[/-][+]Tracking Issue for [*const T|*mut T]::with_metadata_of[/+]Rollup merge of rust-lang#103346 - HeroicKatora:metadata_of_const_poi…
Rollup merge of rust-lang#103346 - HeroicKatora:metadata_of_const_poi…
11 remaining items
GnomedDev commentedon Sep 24, 2024
For the "Is this even needed/useful given that there now also is #81513?", I feel like this is super useful even with or without the metadata APIs.
with_metadatafunction could be added to attach aPointee::Metadatato an existing pointer in future.I'd love to see this stabilized, if that is a good resolution to the last question needed answering.
Noratrieb commentedon Sep 27, 2024
@rust-lang/libs-api see above
scottmcm commentedon Oct 2, 2024
Hmm, I think the primary alternative to this would be something like rust-lang/libs-team#246 -- instead of copying the metadata from a full other pointer, just remove the blocker to letting you pass around the metadata directly.
It's not obvious to me that people really ever want this version where you need to pass a full pointer, just to ignore its address. Or is there some situation I'm not thinking of where that's really better than doing a
let (p, m) = pointer.parts();thenp.whatever().with_metadata(m)?GnomedDev commentedon Oct 3, 2024
As I said above @scottmcm:
My motivating example is https://github.com/andylokandy/smallbox which has been assuming fat pointer layout for years and I recently added a nightly feature which uses this API and strict provenance. Since strict provenance is in the process of being stabilized, this being stabilized as well would be amazing for
smallbox.197g commentedon Oct 3, 2024
RalfJung commentedon Oct 4, 2024
@HeroicKatora IMO it makes little sense to have a function
with_metadata_of<U: ?Sized>(self, other: Metadata<U>) -> *mut U-- that should be calledwith_metadata! Theofpart refers to "with the metadata of another pointer"; if we are directly providing the metadata, we should just say "with this metadata", and there's no "of" involved any more.This tracking issue is specifically about copying the metadata from one pointer to another. Your proposal would be part of #81513.
197g commentedon Oct 4, 2024
I understood @scottmcm as a new question, separate from #81513 itself, to explore whether rust-lang/libs-team#246 changes something about the unresolved redundancy question in the issue. It is not accepted, so not yet a part of #81513 to my understanding (and not linked there either). Maybe I'm misreading the process here.
Neither the API of this (#75091) nor the sketch based on rust-lang/libs-team#246 would require stabilization of the
Metadatatrait itself. I think this affects the merit of the simplicity argument. The representation without address is superior for some library use cases. (It would definitely occur in practice, infact I'm sure my libraries would always prefer the address-less value). I concur, those methods should be namedwith_metadata, notwith_metadata_of, so there's no necessary overlap in the interface and it would of course be possible to have both sets of methods.Are you suggesting the redundancy even with the ACP is slight enough that it would still not be problematic, and there's enough merit to consuming a pointer directly? Definitely a reasonable position to take. I just intended for it to be clarified that the ACP presents a (middle ground) alternative not yet explored in comments in this thread. If libs is in favor of potentially having both that's fine 👍
RalfJung commentedon Oct 4, 2024
All I am saying is, we should not have functions called
with_metadata_ofthat take a pointer and a metadata. That name should only be used for functions that take two pointers.This issue here is specifically about the two-pointer version of the APIs, which avoids stabilizing any new type.
with_metadatain the form you suggested IMO makes a lot of sense (it nicely matcheswith_addras well), but such an API should be proposed in #81513 since it clearly requires talking about "a metadata value matching this pointer type". Whether that is expressed asMetadata<T>or<T as Pointee>::Metadatais a completely orthogonal question.IOW, rust-lang/libs-team#246 is a modification of #81513, but has absolutely no bearing on this issue.
Rollup merge of rust-lang#131339 - HeroicKatora:set_ptr_value-documen…
Rollup merge of rust-lang#131339 - HeroicKatora:set_ptr_value-documen…
Unrolled build for rust-lang#131339
Rollup merge of #131339 - HeroicKatora:set_ptr_value-documentation, r…