Tracking Issue for ByteStr/ByteString #134915
Description
Feature gate: #![feature(bstr)]
This is a tracking issue for the ByteStr/ByteString types, which represent human-readable strings that are usually, but not always, UTF-8. Unlike &str/String, these types permit non-UTF-8 contents, making them suitable for user input, non-native filenames (as Path only supports native filenames), and other applications that need to round-trip whatever data the user provides.
This was approved in ACP rust-lang/libs-team#502 .
Public API
// In core::bstr
#[repr(transparent)]
pub struct ByteStr(pub [u8]);
impl ByteStr {
pub fn new<B: ?Sized + AsRef<[u8]>>(bytes: &B) -> &Self { ... }
}
impl Debug for ByteStr { ... }
impl Display for ByteStr { ... }
impl Deref for ByteStr { type Target = [u8]; ... }
impl DerefMut for ByteStr { ... }
// Other trait impls from bstr, including From impls
// In alloc::bstr
#[repr(transparent)]
pub struct ByteString(pub Vec<u8>);
impl Debug for ByteString { ... }
impl Display for ByteString { ... }
impl Deref for ByteString { type Target = Vec<u8>; ... }
impl DerefMut for ByteString { ... }
// Other trait impls from bstr, including From implsSteps / History
- Implementation: Implement
ByteStrandByteStringtypes #135073 - Final comment period (FCP)1
- Stabilization PR
Unresolved Questions
- Should we call this
BStr/BString, orByteStr/ByteString? The former will be more familiar to users of thebstrcrate in the ecosystem. The latter is more explicit, and avoids potential naming c 6DD4 onflicts (making it easier to, for instance, add it to the prelude). - Should the
Displayimpl use the Unicode replacement character, or do escaping like theDebugimpl? - Add indexing for the new
std::rangetypes, or switch to it exclusively