Is the consideration any different for the mapped RwLock guards?

I recently hit this issue because I wanted to keep the guard around a structure which borrows stored data, but is not such itself, but the current signature forbids such.

Yes, rhe same issue described in the PR also applies to RwLock.

Yes, rhe same issue described in the PR also applies to RwLock.

Guessing you mean your objection on usability grounds in #290? I was mostly wondering if there were additional unsafety / concerns which would make the issue even more problematic for RwLock than it is for Mutex or if it was essentially the same, sorry for not being clear.

I think it's essentially the same.

I ran into this today on RwLock. I want to maintain (roughly) a RwLock<Vec<Mutex<T>> so that individual Ts can be mutated concurrently, locking the whole thing only when adding/removing values, and I want to encapsulate this with an API that returns a smart pointer analogous to MutexGuard, which is internally a RwLockReadGuard<'_, MutexGuard<'_, T>>. However, RwLockReadGuard::map's current signature makes this impossible.

I encountered this as well. Essentially, I need to implement iteration on a type Y that wraps a type X. Instead of reimplementing iteration from scratch, I could wrap the iteration over X by doing the following:

struct Iter<'a>(X::Iter<'a>);

impl<'a> Iterator for Iter<'a> {
    type Item = &'a YElem;
    fn next(&mut self) -> Option<Self::Item> {
        self.0.next().map(|x_elem| &x_elem.y_elem)
    }
}

impl Y {
    fn iter(&self) -> Iter<'_> {
        let guard = self.lock.read();
        Iter(RwLockReadGuard::map(guard, |x| x.iter())) // here, we need to return Iter<'_>, not &'_ …
    }
}