Stack allocated BufWriter (and maybe BufReader)

Is there a crate or std API that has a similar API to Buf{Writer,Reader} and doesn't perform any heap allocations? Since const generics are stable, shouldn't it be possible to implement both the writer and reader using only a stack allocated buffer? I couldn't find a crate for this and was wondering why it isn't part of the stdlib as something like StackBuf{Writer,Reader}. Any reason it shouldn't be part of the stdlib?

You don't need to find a reason it shouldn't be part of the stdlib. You need to find a reason it should be to convince community. Easiest way to prove it is to implement it as a standalone crate published on the crates.io and see how many people find it useful.

Adding something to the stdlib is not a trivial task since once something is included we should maintain it for decades. For example the python stdlib has urllib, urllib2, and urllib3 while the recommended library from the community is the reqwest from pip(python's crates.io). But the python core team need to keep maintaining all 3 of them since otherwise it would be the language's breaking change.

5 Likes

Good point. I'm wondering if that actually works though? I.e. are there examples of code from crates making it into the stdlib? I guess I'm not clear on what would make a crate stdlib worthy.

once_cell is one such example of a popular crate / feature making its way into the standard library, as well as how the core traits of futures have made it in.

2 Likes

Well, at least for the Future trait itself the motivation is different, because it needs to be in the standard library in order for async fn to be able to implement it. But once_cell is a good example.

2 Likes

Thanks for the feedback and examples everyone! It turns out the stdlib implementations never realloc, so I was able to mostly copy them veratem. Here's the crate I created: https://crates.io/crates/stack-buffer.

1 Like