Unseal Buffer trait
Hi!
I find Buffer trait and SpareCapacity quite nice. But having the trait sealed is quite limiting.
Any plans to unseal the the trait so it can be used for own buffer types and own read-like methods? Are the internals too unstable? Would this have any memory safety issues?
I think tokio, bytes, async-std could use this technique too (although, I'm not sure if it's okay for them to depend on rustix)
I've been experimenting with the Buffer trait in a standalone buffer-trait crate, which has an unsealed trait and a more complete API.
Crates like bytes probably won't ever want a dependency on rustix, so buffer-trait is the more likely path forward here. If buffer-trait becomes popular, perhaps rustix should switch to it too.
Also, there has been some interest in the Buffer trait from some Rust folks, as a possible alternative to BorrowedBuf, though there isn't yet an RFC.
Closing, as the buffer-trait crate is the path forward here.
I think this issue was closed prematurely. At the very least, it should've been closed in favor of a new issue dedicated to migration to buffer-trait.
I tried to mirror the rustix API in one of my crates, and Buffer being sealed made it essentially impossible.
If you want to write a wrapper around rustix, I imagined you could use rustix::buffer::Buffer and just forward the buffers to rustix's functions. If you want to write your own code that accepts buffers for your own purposes, I imagined you could use buffer_trait::Buffer, which is unsealed. If neither of those is sufficient for your use case, please file a new issue and describe what you're looking to do.
The problem is that buffer_trait::Buffer does not implement rustix::buffer::Buffer, so I can't pass the former to functions which expect the latter. And I can not get raw pointer and length from rustix::buffer::Buffer which prevents me from using raw functions, so instead of using Buf: Buffer<u8> I had to expose functions which work with raw pointers in my crate.
In other words, I want to mimiс rustix API using a different underlying implementation.