-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Tracking Issue for ByteStr/ByteString #134915
Labels
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Comments
joshtriplett
added
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
labels
Dec 30, 2024
joshtriplett
changed the title
Tracking Issue for BStr/BString
Tracking Issue for ByteStr/ByteString
Dec 30, 2024
In the course of implementing this, I'm addressing BurntSushi/bstr#190 : both the |
joshtriplett
added a commit
to joshtriplett/rust
that referenced
this issue
Jan 3, 2025
Approved ACP: rust-lang/libs-team#502 Tracking issue: rust-lang#134915 These types represent human-readable strings that are conventionally, but not always, UTF-8. The `Debug` impl prints non-UTF-8 bytes using escape sequences, and the `Display` impl uses the Unicode replacement character. This is a minimal implementation of these types and associated trait impls. It does not add any helper methods to other types such as `[u8]` or `Vec<u8>`. I've omitted a few implementations of `AsRef`, `AsMut`, and `Borrow`, when those would be the second implementation for a type (counting the `T` impl), to avoid potential inference failures. We can attempt to add more impls later in standalone commits, and run them through crater. In addition to the `bstr` feature, I've added a `bstr_internals` feature for APIs provided by `core` for use by `alloc` but not currently intended for stabilization. This API and its implementation are based *heavily* on the `bstr` crate by Andrew Gallant (@BurntSushi).
joshtriplett
added a commit
to joshtriplett/rust
that referenced
this issue
Jan 4, 2025
Approved ACP: rust-lang/libs-team#502 Tracking issue: rust-lang#134915 These types represent human-readable strings that are conventionally, but not always, UTF-8. The `Debug` impl prints non-UTF-8 bytes using escape sequences, and the `Display` impl uses the Unicode replacement character. This is a minimal implementation of these types and associated trait impls. It does not add any helper methods to other types such as `[u8]` or `Vec<u8>`. I've omitted a few implementations of `AsRef`, `AsMut`, and `Borrow`, when those would be the second implementation for a type (counting the `T` impl), to avoid potential inference failures. We can attempt to add more impls later in standalone commits, and run them through crater. In addition to the `bstr` feature, I've added a `bstr_internals` feature for APIs provided by `core` for use by `alloc` but not currently intended for stabilization. This API and its implementation are based *heavily* on the `bstr` crate by Andrew Gallant (@BurntSushi).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
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 (asPath
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
Steps / History
ByteStr
andByteString
types #135073Unresolved Questions
BStr
/BString
, orByteStr
/ByteString
? The former will be more familiar to users of thebstr
crate in the ecosystem. The latter is more explicit, and avoids potential naming conflicts (making it easier to, for instance, add it to the prelude).Display
impl use the Unicode replacement character, or do escaping like theDebug
impl?Footnotes
https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩
The text was updated successfully, but these errors were encountered: