# The case for fallible shrinking in Vec
**URL:** https://internals.rust-lang.org/t/the-case-for-fallible-shrinking-in-vec/23924
**Category:** Uncategorized
**Created:** [January 14, 2026, 11:20pm UTC](https://internals.rust-lang.org/t/the-case-for-fallible-shrinking-in-vec/23924 "2026-01-14T23:20:44Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@BitSyndicate](https://internals.rust-lang.org/u/BitSyndicate)
#### Post date: [January 14, 2026, 11:20pm UTC](https://internals.rust-lang.org/t/the-case-for-fallible-shrinking-in-vec/23924/1 "2026-01-14T23:20:45Z")
Currently, the `shrink_to` and `shrink_to_fit` functions on Vec invoke the `handle_alloc_error` function which either panics or aborts the program. This is also the reason the functions are compiled out on builds which do not allow invoking the oom-handler, see the function definition of [`shrink_to` in std](https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#1500), making it impossible to reduce the size of a vectors allocation safely.
```rust
#[cfg(not(no_global_oom_handling))]
#[stable(feature = "shrink_to", since = "1.56.0")]
pub fn shrink_to(&mut self, min_capacity: usize)
```
This can be solved with two different approaches.
## Silent Failure
Currently the documentation for neither `shrink_to` nor `shrink_to_fit` make no guarantees that the allocation will actually be shrunk.
> [`Vec::shrink_to`](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.shrink_to) The capacity will remain at least as large as both the length and the supplied value.
The current allocator api proclaims for the shrink function that
> [`Alllocator::shrink`](https://doc.rust-lang.org/core/alloc/trait.Allocator.html#method.shrink) If this method returns `Err`, then ownership of the memory block has not been transferred to this allocator, and the contents of the memory block are unaltered.
Therefore, `shrinking` could ignore the allocation error returned and proceed as if nothing happened.
## try\_shrink\_\*
This would be my preferred solution to the problem which would be to introduce a mirror of the `try_reserve_*` APIs but for shrinking, so the methods `try_shrink_to` and `try_shrink_to_fit`. This would also makes it clearer to the caller what the current allocation behaviour was.
Although, I am interested in if I am missing something, as I couldn't find any prior discussion about this.
---
### Author:  [@jrose](https://internals.rust-lang.org/u/jrose)
#### Post date: [January 14, 2026, 11:50pm UTC](https://internals.rust-lang.org/t/the-case-for-fallible-shrinking-in-vec/23924/2 "2026-01-14T23:50:09Z")
What are you going to do with the result? _Successful_ shrinking is _also_ allowed to not change the capacity (say, because the allocator only hands out memory in 16-byte chunks and you are trying to shrink a 40-byte vector).
EDIT: withdrawn, kind of. I forgot that the current Allocator API only ever returns a pointer on success, meaning that if shrinking “succeeds”, the caller has to assume it’s exactly the capacity that was requested. I say “kind of” because I think being able to tell the caller what’s _actually_ available would be an improvement to the API, and I know that’s been discussed elsewhere.
---
### Author:  [@quinedot](https://internals.rust-lang.org/u/quinedot)
#### Post date: [January 14, 2026, 11:58pm UTC](https://internals.rust-lang.org/t/the-case-for-fallible-shrinking-in-vec/23924/3 "2026-01-14T23:58:12Z")
> [@BitSyndicate](#):
>
> Therefore, `shrinking` could ignore the allocation error returned and proceed as if nothing happened.
The [`into_boxed_slice`](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.into_boxed_slice) method requires a successful shrinking to soundly return, and I imagine there's other `unsafe` code in the ecosystem that relies on a successful `shrink_to_fit` in an analogous fashion.
---
### Author:  [@BitSyndicate](https://internals.rust-lang.org/u/BitSyndicate)
#### Post date: [January 15, 2026, 8:55am UTC](https://internals.rust-lang.org/t/the-case-for-fallible-shrinking-in-vec/23924/4 "2026-01-15T08:55:21Z")
That rules out solution 1 to the problem then, do you think there is an argument against the `try_shrink_*` functions?
---
### Author:  [@quinedot](https://internals.rust-lang.org/u/quinedot)
#### Post date: [January 15, 2026, 10:01am UTC](https://internals.rust-lang.org/t/the-case-for-fallible-shrinking-in-vec/23924/5 "2026-01-15T10:01:31Z")
Seems reasonable to me.
---
### Author:  [@theemathas](https://internals.rust-lang.org/u/theemathas)
#### Post date: [January 15, 2026, 10:13am UTC](https://internals.rust-lang.org/t/the-case-for-fallible-shrinking-in-vec/23924/6 "2026-01-15T10:13:06Z")
You could file an [ACP](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html#suitability-for-the-standard-library) to get it considered for inclusion in the standard library.