Open tgnottingham opened 4 months ago
cc @LucioFranco
My initial feeling is that I wouldn't want to add such a large new type to the public API of the crate. I can imagine a lot of requests for what a String
-like thing should implement. It's not difficult for projects that want to wrap Bytes
to do something super basic, such as what string
did. True, it doesn't provide a "stable" type that unrelated crates can share.
But our maintenance availability is quite limited.
bytes
has become a little bit of a de facto standard for low/zero-copy techniques, with authors of some popular crates being comfortable with exposingbytes
types in their interfaces. In some cases, those crates would benefit from a bytes string wrapper to enable zero-copy string handling, but they don't support such handling becausebytes
doesn't and they don't want to include another crate likebytestring
, which isn't a de facto standard as of now, in their interfaces.For example,
prost
, which implements conversion between Rust types and protocol buffers, supports usingBytes
instead ofVec<u8>
to back protobuf bytes fields, but it doesn't a similar alternative forString
, despite it being a requested feature (tokio-rs/prost#752), in part becausebytes
doesn't have a string wrapper type.Would the
bytes
maintainers be open to exposing such a type, along the lines of the one described in #373, in order to better enable these use cases in the ecosystem?