Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Mutex::into_inner() #1269

Closed
tomaka opened this issue Sep 3, 2015 · 4 comments
Closed

Add Mutex::into_inner() #1269

tomaka opened this issue Sep 3, 2015 · 4 comments

Comments

@tomaka
Copy link

tomaka commented Sep 3, 2015

impl<T> Mutex<T> {
    pub fn into_inner(self) -> T {
         ...
    }
}

This is very useful for structures like this:

struct Foo {
     data: Mutex<Bar>
}

impl Foo {
    fn modify(&self) {
        self.data.lock().unwrap().modify();
    }

    fn consume(self) {
        let bar = self.data.into_inner();    // oops! doesn't exist
        bar.consume();
    }
}
@sfackler
Copy link
Member

sfackler commented Sep 3, 2015

Seems like a pretty straightforward thing to add - I'm kind of surprised it's not there already.

@alexcrichton
Copy link
Member

We may want into_inner to return LockResult<T>, but other than that I'd also be fine with this. We may also want to go a little further and add:

pub fn get_mut(&mut self) -> LockResult<&mut T>;

because if you have mutable access to a mutex there's no need for synchronization!

bors added a commit to rust-lang/rust that referenced this issue Oct 15, 2015
The implementation for `into_inner` was a bit more complex than I had hoped for---is there any simpler, less unsafe way of getting around the fact that one can't move out of a `Drop` struct?

See #28968 and rust-lang/rfcs#1269 .
@cristicbz
Copy link

This is fixed by rust-lang/rust#29031 with rust-lang/rust#28968 as tracking issue for stabilization.

@alexcrichton
Copy link
Member

Thanks @cristicbz!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants