-
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
Tracking issue for access to Formatter alignment #27726
Comments
Yes, please.
Why? Makes little sense. |
I disagree that it makes little sense to expose getters, it's possible to envision a situation where one formatting is composed of many others and you perhaps want some to be formatted to various widths or perhaps enable various flags (e.g. the "alternate" mode). It's certainly niche but it's somewhat necessary for completeness. |
I would also very much like to add and stabilize boolean accessors for the various parts of I'm a little less sure about |
I'd be fine just deprecating the I'd also be fine making |
This issue is now entering its cycle-long FCP for stabilization in 1.5 The accessors being added in #28615 will also be considered for stabilization. |
Ah, and @SimonSapin, may be good to get your opinion on the grapheme-vs- |
Uh. It’s not just graphemes. The whole
Unfortunately, as often with Unicode, it’s complicated. Not only grapheme clusters can have more than one code point and still only use one slot (with combining code points), but most characters of some Asian languages and most emoji are “full width”: they’re twice the usual width in most monospace fonts. Control characters might or might not be displayed. Or they might be interpreted by the terminal to move the cursor around. http://eev.ee/blog/2015/09/12/dark-corners-of-unicode/#combining-characters-and-character-width has some more background. Here is an extract, about emoji flags:
Our best bet for ”what is the width of this string?” is probably https://github.com/unicode-rs/unicode-width That leaves dealing with |
Hm, those are very good points! I would be mostly tempted to just pare down everything and say it largely deals with ascii only (and maybe simple unicode?). I don't think it'd be too beneficial to start getting full-blown unicode-width support in libcore just to support a use case like this. Having some verification in the compiler, however, to make sure you're not doing crazy things seems reasonable?
In theory, yes.
I'd also be fine with this! |
The libs team discussed this during triage today and the decision was to stabilize. |
This commit stabilizes and deprecates library APIs whose FCP has closed in the last cycle, specifically: Stabilized APIs: * `fs::canonicalize` * `Path::{metadata, symlink_metadata, canonicalize, read_link, read_dir, exists, is_file, is_dir}` - all moved to inherent methods from the `PathExt` trait. * `Formatter::fill` * `Formatter::width` * `Formatter::precision` * `Formatter::sign_plus` * `Formatter::sign_minus` * `Formatter::alternate` * `Formatter::sign_aware_zero_pad` * `string::ParseError` * `Utf8Error::valid_up_to` * `Iterator::{cmp, partial_cmp, eq, ne, lt, le, gt, ge}` * `<[T]>::split_{first,last}{,_mut}` * `Condvar::wait_timeout` - note that `wait_timeout_ms` is not yet deprecated but will be once 1.5 is released. * `str::{R,}MatchIndices` * `str::{r,}match_indices` * `char::from_u32_unchecked` * `VecDeque::insert` * `VecDeque::shrink_to_fit` * `VecDeque::as_slices` * `VecDeque::as_mut_slices` * `VecDeque::swap_remove_front` - (renamed from `swap_front_remove`) * `VecDeque::swap_remove_back` - (renamed from `swap_back_remove`) * `Vec::resize` * `str::slice_mut_unchecked` * `FileTypeExt` * `FileTypeExt::{is_block_device, is_char_device, is_fifo, is_socket}` * `BinaryHeap::from` - `from_vec` deprecated in favor of this * `BinaryHeap::into_vec` - plus a `Into` impl * `BinaryHeap::into_sorted_vec` Deprecated APIs * `slice::ref_slice` * `slice::mut_ref_slice` * `iter::{range_inclusive, RangeInclusive}` * `std::dynamic_lib` Closes rust-lang#27706 Closes rust-lang#27725 cc rust-lang#27726 (align not stabilized yet) Closes rust-lang#27734 Closes rust-lang#27737 Closes rust-lang#27742 Closes rust-lang#27743 Closes rust-lang#27772 Closes rust-lang#27774 Closes rust-lang#27777 Closes rust-lang#27781 cc rust-lang#27788 (a few remaining methods though) Closes rust-lang#27790 Closes rust-lang#27793 Closes rust-lang#27796 Closes rust-lang#27810 cc rust-lang#28147 (not all parts stabilized)
This commit stabilizes and deprecates library APIs whose FCP has closed in the last cycle, specifically: Stabilized APIs: * `fs::canonicalize` * `Path::{metadata, symlink_metadata, canonicalize, read_link, read_dir, exists, is_file, is_dir}` - all moved to inherent methods from the `PathExt` trait. * `Formatter::fill` * `Formatter::width` * `Formatter::precision` * `Formatter::sign_plus` * `Formatter::sign_minus` * `Formatter::alternate` * `Formatter::sign_aware_zero_pad` * `string::ParseError` * `Utf8Error::valid_up_to` * `Iterator::{cmp, partial_cmp, eq, ne, lt, le, gt, ge}` * `<[T]>::split_{first,last}{,_mut}` * `Condvar::wait_timeout` - note that `wait_timeout_ms` is not yet deprecated but will be once 1.5 is released. * `str::{R,}MatchIndices` * `str::{r,}match_indices` * `char::from_u32_unchecked` * `VecDeque::insert` * `VecDeque::shrink_to_fit` * `VecDeque::as_slices` * `VecDeque::as_mut_slices` * `VecDeque::swap_remove_front` - (renamed from `swap_front_remove`) * `VecDeque::swap_remove_back` - (renamed from `swap_back_remove`) * `Vec::resize` * `str::slice_mut_unchecked` * `FileTypeExt` * `FileTypeExt::{is_block_device, is_char_device, is_fifo, is_socket}` * `BinaryHeap::from` - `from_vec` deprecated in favor of this * `BinaryHeap::into_vec` - plus a `Into` impl * `BinaryHeap::into_sorted_vec` Deprecated APIs * `slice::ref_slice` * `slice::mut_ref_slice` * `iter::{range_inclusive, RangeInclusive}` * `std::dynamic_lib` Closes #27706 Closes #27725 cc #27726 (align not stabilized yet) Closes #27734 Closes #27737 Closes #27742 Closes #27743 Closes #27772 Closes #27774 Closes #27777 Closes #27781 cc #27788 (a few remaining methods though) Closes #27790 Closes #27793 Closes #27796 Closes #27810 cc #28147 (not all parts stabilized)
|
I am a bit confused about the reason Is there anything I can help with to move this along? |
@rust-lang/libs Nominating for stabilization. I suspect that src/libfmt_macros/lib.rs
86:pub enum Alignment {
87- /// The value will be aligned to the left.
88- AlignLeft,
89- /// The value will be aligned to the right.
90- AlignRight,
91- /// The value will be aligned in the center.
92- AlignCenter,
93- /// The value will take on a default alignment.
94- AlignUnknown,
95-}
src/libcore/fmt/mod.rs
31:pub enum Alignment {
32- /// Indication that contents should be left-aligned.
33- Left,
34- /// Indication that contents should be right-aligned.
35- Right,
36- /// Indication that contents should be center-aligned.
37- Center,
38- /// No alignment was requested.
39- Unknown,
40-}
src/libcore/fmt/rt/v1.rs
35:pub enum Alignment {
36- /// Indication that contents should be left-aligned.
37- Left,
38- /// Indication that contents should be right-aligned.
39- Right,
40- /// Indication that contents should be center-aligned.
41- Center,
42- /// No alignment was requested.
43- Unknown,
44-} |
I think we should remove @rfcbot fcp merge |
Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
1 similar comment
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period is now complete. |
Shouldn't this get merged then? |
Yes, with FCP to stabilize completed, the next step is a stabilization PR. |
Stabilize Formatter alignment Fixes #27726. cc @SimonSapin
Tracking issue for the
fmt_flags_align
feature, which isfmt::Formatter::align
and the associated enum.The text was updated successfully, but these errors were encountered: