Tracking Issue for smart pointer (try_)map

Feature gate: #![feature(smart_pointer_try_map)]

This is a tracking issue for map and try_map functions for various smart pointer types, as per rust-lang/libs-team#364

Public API

// Taking T by value
impl Box<T> {
    fn map<U>(this: Self, f: impl FnOnce(T) -> U) -> Box<U>;
    fn try_map<R>(this: Self, f: impl FnOnce(T) -> R) -> ChangeOutputType<R, Box<R::Output>>
    where
        R: Try,
        R::Residual: Residual<Box<R::Output, A>>;
}
impl UniqueRc<T> {
    fn map<U>(this: Self, f: impl FnOnce(T) -> U) -> UniqueRc<U>;
    fn try_map<R>(this: Self, f: impl FnOnce(T) -> R) -> ChangeOutputType<R, UniqueRc<R::Output>>
    where
        R: Try,
        R::Residual: Residual<UniqueRc<R::Output, A>>;
}
impl UniqueArc<T> {
    fn map<U>(this: Self, f: impl FnOnce(T) -> U) -> UniqueArc<U>;
    fn try_map<R>(this: Self, f: impl FnOnce(T) -> R) -> ChangeOutputType<R, UniqueArc<R::Output>>
    where
        R: Try,
        R::Residual: Residual<UniqueArc<R::Output, A>>;
}

// Taking T by reference
impl Rc<T> {
    fn map<U>(this: Self, f: impl FnOnce(&T) -> U) -> Rc<U>;
    fn try_map<R>(this: Self, f: impl FnOnce(&T) -> R) -> ChangeOutputType<R, Rc<R::Output>>
    where
        R: Try,
        R::Residual: Residual<Rc<R::Output, A>>;
}
impl Arc<T> {
    fn map<U>(this: Self, f: impl FnOnce(&T) -> U) -> Arc<<U>;
    fn try_map<R>(this: Self, f: impl FnOnce(&T) -> R) -> ChangeOutputType<R, Arc<<R::Output>>
    where
        R: Try,
        R::Residual: Residual<Arc<R::Output, A>>;
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

Implementation: smart pointer (try_)map #144420
Final comment period (FCP)¹
Stabilization PR

Unresolved Questions

ACP: Add {Box, Rc, Arc}::map and {Box, Rc, Arc}::try_map libs-team#364 (comment)

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

I see in the linked PR that if size or alignment of the input and output type don't match, then it falls back to Box::new(f(*this)). This sort of makes sense but it kind of defeats the purpose of the function. What about returning a compiler error instead, if size or alignment don't match?

Rollup merge of rust-lang#144420 - Qelxiros:smart_pointer_try_map, r=…

Auto merge of #144420 - Qelxiros:smart_pointer_try_map, r=joboet

@tmke8

@tmke8 That makes the function unusable in generic code (e.g. Box<T> -> Box<T::Foo> where T: HasFoo), big downvote from me.

Auto merge of rust-lang#144420 - Qelxiros:smart_pointer_try_map, r=jo…

Well, I was imagining that the compiler error would be thrown on monomorphization, in which case your code would work fine, I think. But I have to admit I'm not an expert on where compiler errors can be raised.

EDIT: sorry, "static assert" is a much better term for what I was imagining than "compiler error"

EDIT2: e.g., using something like this: https://docs.rs/static_assertions/latest/static_assertions/macro.assert_eq_align.html

Rollup merge of rust-lang#160534 - Qelxiros:stabilize-smart-pointer-m…

Unrolled build for #160534 in rollup 162117

Rollup merge of #160534 - Qelxiros:stabilize-smart-pointer-map, r=nia-e

I find this API to be a bit surprising, I would rather expect Arc's map method to work more like MappedMutexGuard.

use std::ops::Deref;
use std::ptr::NonNull;
use std::sync::Arc;

struct MappedArc<T, U> {
    _arc: Arc<T>,
    ptr: NonNull<U>,
}

impl<T, U> MappedArc<T, U> {
    fn new(arc: Arc<T>, callback: impl FnOnce(&T) -> &U) -> Self {
        let ptr = NonNull::from_ref(callback(&arc));
        Self { _arc: arc, ptr }
    }
}

impl<T, U> Deref for MappedArc<T, U> {
    type Target = U;
    fn deref(&self) -> &U {
        // safe because Arc still exists (it's owned by MappedArc)
        unsafe { self.ptr.as_ref() }
    }
}

fn main() {
    let arc = Arc::new((2, 3, 4));
    let mapped = MappedArc::new(arc, |x| &x.1);
    println!("{:?}", *mapped);
}

Something like could be pretty useful especially for async code, due to the fact that async code tends to be Arc heavy.

I think the docs could be clearer about the conditions for reusing the allocation. I wasn't sure if it would reuse the allocation if the mapped value is smaller.

I'd avoid guaranteeing it regardless - at best we could make it a grow/shrink call, but promising reuse of the allocation would require us to track the original layout used to make the allocation

I think it's harmless to guarantee it when T's size and alignment match that of U (which is also the only time we do it currently).

That's probably fair. Some part of me is scared that it'll turn out to be weird for some reason I've yet to think of but I'd be okay +1'ing that (will need fcp)

Navigation Menu

Repository navigation

Tracking Issue for smart pointer (try_)map #144419

Public API

Steps / History

Unresolved Questions

23 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for smart pointer (try_)map #144419

Description

Public API

Steps / History

Unresolved Questions

Footnotes

Activity

tmke8 commented on Sep 21, 2025

orlp commented on Nov 5, 2025

tmke8 commented on Nov 11, 2025

23 remaining items

sugar700 commented on Sep 3, 2026

camsteffen commented on Sep 4, 2026

nia-e commented on Sep 4, 2026

orlp commented on Sep 4, 2026

nia-e commented on Sep 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions