Precision for debug formatting works with empty tuple, but not other things (odd inconsistency)

[ids1024]

It may be intentional that precision doesn't work with debug formatting (only with display), but this inconsistency is odd.

println!("{:?}", ()); // prints '()'
println!("{:.0?}", ()); // prints ''
println!("{:.1?}", ()); // prints '('

// In all of the below, the precision specifier has no effect at all;
// the full debug text is printed
println!("{:.0?}", 125);
println!("{:.1?}", 125);
println!("{:.0?}", (1, 2, 3));
println!("{:.1?}", (1, 2, 3));
println!("{:.0?}", ((), (), ()));
println!("{:.1?}", ((), (), ()));
println!("{:.0?}", "test");
println!("{:.1?}", "test");

I presume this is unintended (I can't imagine why it would be intentional)? Although any change may technically be breaking. Of course, if it is desired that precision doesn't work with debug, it doesn't really matter since there's no reason to use it.

[ids1024]

The reason for this, as for as code, is that f.pad() is used in the implementation of Debug for (), but not for the other types I've tried.

In src/libcore/fmt/mod.rs:

impl Debug for () {
    fn fmt(&self, f: &mut Formatter) -> Result {
        f.pad("()")
    }
}

impl Debug for str {
    fn fmt(&self, f: &mut Formatter) -> Result {
        f.write_char('"')?;
        let mut from = 0;
        for (i, c) in self.char_indices() {
            let esc = c.escape_debug();
            // If char needs escaping, flush backlog so far and write, else skip
            if esc.len() != 1 {
                f.write_str(&self[from..i])?;
                for c in esc {
                    f.write_char(c)?;
                }
                from = i + c.len_utf8();
            }
        }
        f.write_str(&self[from..])?;
        f.write_char('"')
    }
}

That of course doesn't answer the question of what the intended behavior is; presumably the inconsistency isn't intended.

[dtolnay]

I agree that this does not seem intentional. I would love a PR with a fix!

[ids1024]

Is the preferred solution to make () behave like everything else?

I was hoping precision specifiers would work in debug formatting (though, my use case was a bit of a hack); but getting that to work is complicated and somewhat problematic.

Either way, it is technically a breaking change, but presumably no one is really relying on it since it doesn't do anything useful.

[dtolnay]

According to the std::fmt documentation, the intended behavior is:

For non-numeric types, this can be considered a "maximum width". If the resulting string is longer than this width, then it is truncated down to this many characters and that truncated value is emitted with proper fill, alignment and width if those parameters are set.

Do you have a sense of how complicated and problematic it would be to adhere to what the doc says?

[masklinn]

Just found this issue after encountering a similar problem: a type with derive(Debug) did not respond to formatting information which was somewhat odd (and made me spend some time before concluding that it was intended and not an error of my code), what would be the intended behavior here:

• should Debug generally respond to formatting information by default aka the empty tuple behaves properly and the rest does not and should be fixed (probably including derive(Debug))
• should Debug generally not respond to formatting information, the empty tuple should not, and maybe there should be some sort of warning emitted when trying to combine formatting with :?, either a built-in lint, or more of a clippy concern? The one issue with the warning would be the possible false positive when using :? on types with a custom Debug implementation, but I don't really know how common custom Debug implementations are and more importantly how often they implement support for formatting specifier.

[RodBurman]

With the current rust version:

% cargo -v -V
cargo 1.84.0 (66221abde 2024-11-19)
release: 1.84.0
commit-hash: 66221abdeca2002d318fde6efff516aab091df0e
commit-date: 2024-11-19
host: aarch64-apple-darwin
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.7.1 (sys:0.4.74+curl-8.9.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 15.3.0 [64-bit]

The test code produces:

()

(
125
125
(1, 2, 3)
(1, 2, 3)
(, , )
((, (, ()
"test"
"test"

So in over 7 years this issue has does not seem to have changed at all. "Fixing" the empty tuple so it always prints as "()" would seem simplest and it could be documented that debug accepts but does not respond to format modifiers. Alternatives are to make debug respond for all types (which sounds like a lot of work) or add a warning to clippy or the compiler when format modifiers are used with debug with suitable wording about uncertain behaviour.