Change:
/// } /// # process_data("123").expect("why is the test harness OOMing on 3 bytes?"); /// ``` <del> #[unstable(feature = "try_reserve_2", issue = "91789")] </del> <ins> #[stable(feature = "try_reserve_2", since = "1.63.0")] </ins> #[inline] pub fn try_reserve(&mut self, additional: usize) -> Result<(), TryReserveError> { self.inner.try_reserve(additional)

Discussion:
<!-- NOTE: For library features, please use the "Library Tracking Issue" template instead. Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is another tracking issue for the tryreserve part of the RFC "fallible collection allocation" (rust-lang/rfcs). The feature gate for the issue is . The feature is a follow-up to . Since was stabilized in 1.57.0, we may need a new feature gate for further implementation on more containers. Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement and on [x] Implement and on [x] Implement and on [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- If any containers were missing, please comment in the issue, and I will add it to the list. <!-- Include any open questions that need to be answered before the feature can be stabilised. --<!-- Include a list of all the PRs that were involved in implementing the feature. --
After a diff between and , I think the current list is complete.

I'm interested in implement tryreserve and tryreserve_exact on PathBuf.
Please help update the issue link into description:
And the support of will be based on work , I will continue it after this PR get merged.
has been submitted for review. Let's go forward the stabilization!
Let's stabilize this feature! Steps are listed here: From https://rustc-dev- [x] Ask a T-libs-api member to start an FCP on the tracking issue and wait for the FCP to complete [x] Change to [x] Remove from any test or doc-test for this API [x] Open a PR against Add the appropriate labels: . Link to the tracking issue and say "Closes #XXXXX".
Hi, can you help start an FCP for feature ?
Absolutely! merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [ ] [x] [x] [x] Concerns: resolved by Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
It's worth being aware that the version of these methods is extremely weird, and probably not adequately documented about how weird it is. In particular the following "obvious" code is not correct, but it seems likely that almost every caller would fall into this trap unless there is very clear guidance on how to use the method correctly. The units in which string length is measured, and the units in which OsString capacity is measured, are in general totally different units. Quoting from elsewhere in the OsString docs: This is saying that the "storage size" of an OS string (which is the size that returns, and the same units as the arg of ) "may differ significantly" from the storage size of the "Rust string form" of the same data, i.e. that and may differ significantly. concern do we need better docs about what the argument value means (not bytes)
I definitely agree that is very easy to be used incorrectly, but I think the problem already exists due to the API. Users may also got wrong results while they use with_capacity from another type’s len().

I agree that also needs to be better explained. That function is from 2016 when our standards were lower. :wink:
I will start PRs to address the concern that proposed. [ ] Add better docs for about what the argument value means [ ] (Maybe) Polish the docs for too ?
We should probably just update that documentation. We already guarantee any can be turned into a through , so there's not much room for doing anything other than representing data exactly as is in an , with the same length. So your example snippet will work fine. The only space left for 'surprises' is how many units/bytes unmatched UTF-16 surrogate pair halves take on Windows.
Sorry for stalling this work for so long; I'll take care of all the concerns next week.
sounds good to me. I would be prepared to accept (with libs-api FCP) a PR that updates all the places talking about OS string capacity to indicate that this means UTF-8 byte size for OS strings which were created from valid unicode, and not otherwise specified for other contents.
Great, please take a look at
resolve do we need better docs about what the argument value means (not bytes)
:bell: This is now entering its final comment period, as per the . :bell:
look like  have been forgotten too. Don't know what would be the plan for 
IMHO, we need a proposal to discuss adding for and first.
BTreeSet and LinkedList are pointer-based data structure, which means that they can't benefit from batch allocation. The reserve method on them is exactly same as just allocate one by one, but will make the code much more complicated (we have to introduce placeholder nodes for that).
ah I get fouled by these two collections probably need something like instead.