You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 exposing bytes 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 because bytes doesn't and they don't want to include another crate like bytestring, 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 using Bytes instead of Vec<u8> to back protobuf bytes fields, but it doesn't a similar alternative for String, despite it being a requested feature (tokio-rs/prost#752), in part because bytes 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?
The text was updated successfully, but these errors were encountered:
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?The text was updated successfully, but these errors were encountered: