Tracking Issue for cell_filter_map

[KodrAus]

Feature gate: #![feature(cell_filter_map)]

This is a tracking issue for Ref::filter_map and RefMut::filter_map, which lets you optionally project data inside a Ref or RefMut, wrapped in a Ref or RefMut. If the projection returns None then these methods return a Err(Self) so that you can still get the original Ref or RefMut back out.

Public API

impl<'b, T: ?Sized> Ref<'b, T> {
    pub fn filter_map<U: ?Sized, F>(orig: Ref<'b, T>, f: F) -> Result<Ref<'b, U>, Self>
    where
        F: FnOnce(&T) -> Option<&U> {}
}

impl<'b, T: ?Sized> RefMut<'b, T> {
    pub fn filter_map<U: ?Sized, F>(orig: RefMut<'b, T>, f: F) -> Result<RefMut<'b, U>, Self>
    where
        F: FnOnce(&mut T) -> Option<&mut U> {}
}

Steps / History

• Implementation: Introduce {Ref, RefMut}::try_map for optional projections in RefCell #78455
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• Naming and signature: We wanted to call this method try_map and accept a closure like FnOnce(&T) -> R where R: Try<Ok = &U>, but that's not sound with bound lifetimes. This method is only ok when the mapping closure uses HRTB. So we opted to call it filter_map instead, with the closure returning a Option<&U>.

[Robbepop]

I am in need of this API for my library in order to be able to have an efficient implementation that avoids unsafe Rust code.
I wonder, why is the goal to have try_map instead of filter_map since I can see a great value in having both APIs available.
So if filter_map is already good to go we could stabilize that one and later add try_map as soon as all open questions for it are resolved.

[hniksic]

The name filter_map() seems unusual for something that returns a Result - for example, Iterator::filter_map() returns an iterator with filtering built in. The equivalent method already exists in the Mutex implementations of tokio and parking_lot, under the name try_map(). In both cases the closure it accepts returns Option<&U> and not the more general impl Try. So maybe the name try_map should be reconsidered in that light.

[lucassardois]

I'm also interested in the stabilization of this API for the same reason as @Robbepop. However, I also agree that filter_map() should be named try_map() since it returns a Result. As an API user it makes more sense to me.

[tony612]

I wonder if we can have a generic filter & map for any inner enum instead of just Option.

For example in this code

pub enum Foo<T> {
    A(),
    B(T),
}

pub struct Bar {}

pub struct User {
    pub data: RefCell<Foo<Bar>>,
}

impl User {
    pub fn get_data(&self) -> std::result::Result<Ref<'_, Bar>, String> {
        let v = self.data.borrow();
        if let Foo::B(_) = *v {
            Ok(Ref::map(v, |x| match x {
                Foo::B(b) => b,
                _ => unreachable!(),
            }))
        } else {
            Err(String::from("error"))
        }
    }
}

As the code show, data ref is compared twice to get the result. Is there any way to make it simpler?

[m-ou-se]

@rfcbot fcp merge

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.