-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
std_unicode::char::decode_utf16
should be in core
#49319
Labels
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Comments
This was referenced Mar 24, 2018
I agree that there is no reason for this not to be in libcore. Feel free to submit a PR and ping me for review. More generally I wonder if we can rely of various platforms’ linkers to remove unused tables, and if so if there’s any reason to keep |
cuviper
added
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
labels
Mar 24, 2018
#49698 fixes this. |
bors
added a commit
that referenced
this issue
Apr 11, 2018
Merge the std_unicode crate into the core crate [The standard library facade](#27783) has historically contained a number of crates with different roles, but that number has decreased over time. `rand` and `libc` have moved to crates.io, and [`collections` was merged into `alloc`](#42648). Today we have `core` that applies everywhere, `std` that expects a full operating system, and `alloc` in-between that only requires a memory allocator (which can be provided by users)… and `std_unicode`, which doesn’t really have a reason to be separate anymore. It contains functionality based on Unicode data tables that can be large, but as long as relevant functions are not called the tables should be removed from binaries by linkers. This deprecates the unstable `std_unicode` crate and moves all of its contents into `core`, replacing them with `pub use` reexports. The crate can be removed later. This also removes the `CharExt` trait (replaced with inherent methods in libcore) and `UnicodeStr` trait (merged into `StrExt`). There traits were both unstable and not intended to be used or named directly. A number of new items are newly-available in libcore and instantly stable there, but only if they were already stable in libstd. Fixes #49319.
bors
added a commit
that referenced
this issue
Apr 12, 2018
Merge the std_unicode crate into the core crate [The standard library facade](#27783) has historically contained a number of crates with different roles, but that number has decreased over time. `rand` and `libc` have moved to crates.io, and [`collections` was merged into `alloc`](#42648). Today we have `core` that applies everywhere, `std` that expects a full operating system, and `alloc` in-between that only requires a memory allocator (which can be provided by users)… and `std_unicode`, which doesn’t really have a reason to be separate anymore. It contains functionality based on Unicode data tables that can be large, but as long as relevant functions are not called the tables should be removed from binaries by linkers. This deprecates the unstable `std_unicode` crate and moves all of its contents into `core`, replacing them with `pub use` reexports. The crate can be removed later. This also removes the `CharExt` trait (replaced with inherent methods in libcore) and `UnicodeStr` trait (merged into `StrExt`). There traits were both unstable and not intended to be used or named directly. A number of new items are newly-available in libcore and instantly stable there, but only if they were already stable in libstd. Fixes #49319.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
The
decode_utf16
function currently lives in thestd_unicode
crate. But, as far as I can tell, this function doesn't depend on any Unicode tables and has no reason to be in this crate.I suggest moving this function (and its associated iterator) into the
core
crate. This will allow for decoding UTF-16 text under#![no_std]
in stable Rust.The text was updated successfully, but these errors were encountered: