Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose UTF-8 validated string type #697

Open
tgnottingham opened this issue Apr 23, 2024 · 2 comments
Open

Expose UTF-8 validated string type #697

tgnottingham opened this issue Apr 23, 2024 · 2 comments

Comments

@tgnottingham
Copy link

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?

@Darksonn
Copy link
Contributor

cc @LucioFranco

@seanmonstar
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants