Skip to content
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 hexadecimal integers with fmt::Debug output #48584

Closed
alexcrichton opened this issue Feb 27, 2018 · 4 comments
Closed

Tracking issue for hexadecimal integers with fmt::Debug output #48584

alexcrichton opened this issue Feb 27, 2018 · 4 comments
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@alexcrichton
Copy link
Member

This is a tracking issue for rust-lang/rfcs#2226, @SimonSapin mind filling in some details here?

@alexcrichton alexcrichton added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Feb 27, 2018
@SimonSapin
Copy link
Contributor

SimonSapin commented Mar 13, 2018

Implementation PR: #48978
RFC: https://rust-lang.github.io/rfcs/2226-fmt-debug-hex.html

In formatting strings (in format! and related macros), this adds two "formatting types" x? and X? (in addition to the existing x, ?, p, etc) that make integers be formatted in (lower- or upper-case) hexadecimal with the fmt::Debug trait. This is useful when a composite type implements fmt::Debug (for example a struct with #[derive(Debug)]) but not fmt::LowerHex or fmt::UpperHex, and contains integers or a slice of integers or a byte string.

For example:

assert!(format!("{:02x?}", b"Foo\0") == "[46, 6f, 6f, 00]");
assert!(format!("{:02X?}", b"Foo\0") == "[46, 6F, 6F, 00]");

@shepmaster
Copy link
Member

I assume this should be closed now that it's shipped in 1.26.0 stable?

@TyPR124
Copy link
Contributor

TyPR124 commented Jan 7, 2020

Is there still intent to make the debug_upper_hex and debug_lower_hex flags public? See:

rust/src/libcore/fmt/mod.rs

Lines 1743 to 1751 in ef92009

// FIXME: Decide what public API we want for these two flags.
// https://github.com/rust-lang/rust/issues/48584
fn debug_lower_hex(&self) -> bool {
self.flags & (1 << FlagV1::DebugLowerHex as u32) != 0
}
fn debug_upper_hex(&self) -> bool {
self.flags & (1 << FlagV1::DebugUpperHex as u32) != 0
}

I would find these useful.

@Kimundi
Copy link
Member

Kimundi commented Feb 21, 2021

I just "rediscovered" these {:x?} formatting options. A short summary of the history here:

  • Hexadecimal integers with fmt::Debug, including within larger types rfcs#2226 proposed this feature, including:
    • grammar changes to the formatting syntax to account for the new radix position where the x gets inserted in {:x?}
    • new fmt::Formatter APIs for querying that value
    • extension of the Debug impl for integers to conditionally delegate to fmt::LowerHex or fmt::UpperHex if this is set.
  • Discussion on the original RFC thread lead to open questions about how to design the Formatter API in a way that is future-proof with possible other extensions like this.
  • As reaction to that, it got implemented in Add hexadecimal formatting of integers with fmt::Debug #48978 without public Formatter API changes.

However, as a result of this the discoverability of this feature is kinda bad, as the only way to know about it is to read the two lines in std::fmt's docs that talk about it. Otherwise it's completely internal magic hidden between the Formatter type and Debug impls for integers, that can not be externally used for something else, and is thus completley invisible in the API.

This is also confusing because the syntax section in std::fmt's docs never got updated with the new grammar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants