We should decide whether take_mut is sound

[RalfJung]

The take_mut and replace_with crates have been around since forever and, despite being unmaintained, has tons of downloads. I am sure variants of this pattern have been copied into many other places; at least one such copy exists in the standard library. However, take_mut is in a soundness conflict with other patterns, such as partial_borrow and the WontDrop from this Zulip comment. Both of those rely on mutable references being "pinned" in some sense, while wanting to avoid the overhead of Pin to make that pinning explicit in the type system.

This means the soundness status of take_mut is undecided. (Note that even if take_mut is unsound, some instances of the pattern may be sound, so e.g. the use in the standard library may still be fine. It just means the safety argument for why that code is fine needs to be more complicated than it currently is.) I think it is harmful to leave the ecosystem in limbo about whether this pattern is sound. We should officially decide one way or the other, by blessing one of the APIs as sound. The most direct way of doing that would be having something in the standard library, but we could also consider having a collection of "operations we consider sound but not common enough to have in the standard library" somewhere. Not sure where.

My personal preference would be to say that take_mut/replace_with are sound. I consider this "natural" since in a formal model of Rust (such as RustBelt), if you don't do anything special for mutable references, this is what will happen. It falls out of the fact that all types are movable. We have pinning any maybe eventually !Move types to properly indicate when something should not be movable.

This has previously been suggested in rust-lang/rfcs#1736 and was closed (10 years ago) because it was considered a footgun to have such implicit aborts in the standard library. We seem more ready to accept implicit aborts these days, such as around extern "C" functions. I think not resolving this soundness conflict is a much worse footgun.

I am not sure which team would be in charge of such a decision, but I suspect both lang and libs since this is about a decision on the safety contract of a built-in type (lang) that is best exposed via a std API (libs).
Cc @rust-lang/lang @rust-lang/libs @rust-lang/libs-api

[RalfJung]

@programmerjake suggested a related API we might also somehow want to explicitly declare as sound:

fn take_from_mut<T>(v: &'static mut T) -> T;

[QuineDot]

@programmerjake suggested a related API we might also somehow want to explicitly declare as sound:

That's #125868.

[RalfJung]

Right, so if take_mut/replace_with is sound then take_from_mut is sound for Send types.

[ais523]

I'm trying to figure out what would/might make take_from_mut unsound for !Send types, and can't – &mut T: Send if and only if T: Send, so if it's safe to send the resulting value it was also safe to send the reference, and vice versa. Am I missing something?

[programmerjake]

Right, so if take_mut/replace_with is sound then take_from_mut is sound for Send types.

I think take_from_mut is just as sound for !Send types, the quoted text just comes from a (bad, but theoretically important) implementation in terms of replace_with:
https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/.60from_static.60.3A.20a.20.60take_mut.60.20in.20an.60.26own.60.20world/near/616922093

fn take_from_mut<T: Send>(reference: &'static mut T) -> T {
    let (sender, receiver) = std::sync::mpsc::channel();
    std::thread::spawn(move || {
        replace_with::replace_with_or_abort(reference, |t| {
            let _ = sender.send(t);
            loop {}
        })
    });
    
    receiver.recv().unwrap()
}

[nia-e]

hey, thanks for raising this! on the libs side, we had some discussion over this but per today's meeting we would indeed prefer semantics that let take_mut be sound

[RalfJung]

Would you also be willing to have take_mut/replace_with in some form in libcore, or would you prefer we find some other way to declare it as sound?

[nia-e]

i suppose that would need to go through ACP, but i for one would second such an ACP given we decided it's sound