Expose UTF-8 validated string type

[tgnottingham]

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]

cc @LucioFranco

[seanmonstar]

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.

[LambdaP]

I'm wondering if a good compromise would be to have a crate bytes-extra that would offer extra utilities (like tower-extra does). This would allow bytes to remain small, while offering a more authoritative implementation of e.g., a String-like interface, as at the moment it looks like a few crates aim at doing what this issue is asking.

For example, this new crate could offer functionalities like https://github.com/vorner/bytes-utils does (although I don't have an opinion about the implementation of that specific crate).