Add `PathBuf::leak` & `OsString::leak`

[its-the-shrimp]

Proposal

Add a leak method to std::path::PathBuf & std::ffi::OsString

Problem statement

String, Vec, OsString, PathBuf, all 4 are common container types in the standard library, however, only 2 of them implement a way to leak their allocated memory: String & Vec, OsString & PathBuf are missing this functionality for no good reason.

Motivating examples or use cases

Aside from simple consistency in the APIs, a use case for leaking OsStrings & PathBufs which prompted me to write this proposal is using arguments provided through the CLI to perform a certain task that requires the strings to be shared, potentially across multiple threads.

Solution sketch

impl OsString {
    fn leak<'a>(self) -> &'a mut OsStr { ... }
}

impl PathBuf {
    fn leak<'a>(self) -> &'a mut Path { ... }
}

Alternatives

The alternative is to do nothing, and force the users to leak OsStrings & PathBufs via

Box::leak(path_buf.into_boxed_path())

or

Box::leak(os_string.into_boxed_os_str())

Which doesn't seem to be justified by anything

Links and related work

https://doc.rust-lang.org/nightly/std/string/struct.String.html#method.leak
https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html#method.leak
https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.leak

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[its-the-shrimp]

I already have a half-finished impl of this that I'll submit if this is accepted

[ChrisDenton]

Box::leak(os_string.into_boxed_os_str())

I believe this can also now be done via:

unsafe { OsStr::from_encoded_bytes_unchecked(os_string.into_encoded_bytes().leak()) }

But removing the need for unsafe would, I think, be a justification for just having a direct leak method.

[its-the-shrimp]

Yes, another, albeit trivial, point is that leaking a Box, while being safe, discards the extra unused space, which might incur a reallocation

[pitaj]

Yes, another, albeit trivial, point is that leaking a Box, while being safe, discards the extra unused space, which might incur a reallocation

Only applies to OsString since you could do Path::new(pb.into_os_string().leak()) once you have OsString::leak.

[dtolnay]

Thanks for the ACP. Makes sense to me -- I am ready to accept a PR adding the 2 proposed methods as unstable.