`format_args` deduplicates consts with interior mutability or destructor

[theemathas]

I'm not sure if this is a bug or not.

I tried this code:

use std::fmt::{self, Display, Formatter};
use std::cell::Cell;

struct PrintCounter(Cell<usize>);

impl Display for PrintCounter {
    fn fmt(&self, f: &mut Formatter) -> fmt::Result {
        let counter = 1 + self.0.get();
        self.0.set(counter);
        write!(f, "{counter}")
    }
}

const ZERO: PrintCounter = PrintCounter(Cell::new(0));

fn main() {
    println!("{ZERO}, {ZERO}");
}

I expected the code to print 1, 1, since I am creating two separate PrintCounter values and printing them separately.

Instead, it printed 1, 2. The compiler seemed to have deduplicated the two mentions of ZERO into one mention.

Note that if the code is modified to be println!("{}, {}", ZERO, ZERO);, then it correctly prints 1, 1.

@rustbot labels +A-fmt

Meta

Reproducible on the playground with version 1.91.0-nightly (2025-08-20 040a98af70f0a7da03f3)

[theemathas]

It is possible that this is working as intended, although this behavior is very strange.

RFC 2795 says:

If this proposal were captured, the following (currently invalid) macro invocation: format_args!("hello {person}") would become a valid macro invocation, and would be equivalent to a shorthand for the already valid: format_args!("hello {person}", person=person)

This desugaring would naturally result in deduplicating consts (the current behavior), since having multiple named arguments with the same name doesn't make much sense.

[theemathas]

This also affects consts with destructors.

The following code prints drop only once, instead of twice:

#[derive(Debug)]
struct LoudDrop;

impl Drop for LoudDrop {
    fn drop(&mut self) {
        println!("drop");
    }
}

fn main() {
    println!("{LoudDrop:?}, {LoudDrop:?}");
}

@rustbot labels +A-const-eval +A-destructors

[kpreid]

As I see it, this surprise comes from conflict between two different interpretations of the meaning of the syntax. Here are citations for both of these interpretations:

1. RFC 2785 says:

   If this proposal were captured, the following (currently invalid) macro invocation:

   format_args!("hello {person}")

   would become a valid macro invocation, and would be equivalent to a shorthand for the already valid:

   format_args!("hello {person}", person=person)

   Under this interpretation, the current behavior is exactly correct: there can only be one key-value pair with a given key, so there is only one value expression to evaluate, too.

2. On the other hand, the standard library documentation says:

   If a named parameter does not appear in the argument list, format! will reference a variable with that name in the current scope.

   This sentence can be taken as saying that captures should not be translated into key-value pairs, but are their own distinct thing which occurs only when there is not a matching key in the arguments. (Or, extremely pedantically, we could say that a const item is not a variable, and so this sentence gives no meaning to mentioning a const item in a format string. But, I think, nobody wants that.)

   Under this interpretation, the current behavior is incorrect.

A factor worth noting is that interpretation 2 is more friendly to the possibility of expanding format strings to allow more kinds of expressions than single identifiers. (I personally think doing so would be unwise, but I don’t care to argue that point.)