I think I reach the opposite conclusion which is that I'd not take a library dependency to get the non-growable version. I would however like push_within_capacity (currently available on Vec in nightly) so that I can express the idea "I would prefer to push this into the ring buffer but I have some plan B if there's no room"
Interesting, I hadn't seen `push_within_capacity` before! I'm a bit surprised to see that the implementation for it is using unsafe rather than just calling `push` after returning an error if it's at max capacity already. Given that my understanding is that it's safe if there's spare capacity, my instinct is that "a logic bug in the implementation will mistakenly cause an allocation" is strictly better than "a logic bug in the implementation will mistakenly cause UB", given that UB might _also_ end up allocating, or do any number of other things. Other than that, the only difference I can think of is that calling `push` would potentially introduce a function call that isn't inlined, but that seems like it could be solved by having a helper method (or function in the `vec` module) marked as `inline(always)`, and that seems preferable to me than using unsafe code just to avoid the extra definition.
Unless I'm missing something, the implementation using `push` would also be possible to mimic via the current stable public API of `Vec`, it might take 50 lines of code[1] to define a wrapper type with this method, so I'm with that this isn't something that I'd pull in a dependency for.
