Closed its-the-shrimp closed 4 months ago
I already have a half-finished impl of this that I'll submit if this is accepted
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.
Yes, another, albeit trivial, point is that leaking a Box, while being safe, discards the extra unused space, which might incur a reallocation
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
.
Thanks for the ACP. Makes sense to me -- I am ready to accept a PR adding the 2 proposed methods as unstable.
Proposal
Add a
leak
method tostd::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
OsString
s &PathBuf
s 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
Alternatives
The alternative is to do nothing, and force the users to leak
OsString
s &PathBuf
s viaor
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):
Second, if there's a concrete solution: