External Publication
Visit Post

Change error message of a failing `assert_eq!`

Rust Internals [Unofficial] April 1, 2026
Source

mathstuf:

Perhaps it is down to coding style, but actual is usually a variable whereas expected is either hand-typed or also pulling a local variable (e.g., to make sure a configuration value gets through).

Right, this is definitely a coding style thing - I wasn't proposing that this is universal or even common in Rust, just that you can argue for the exact opposite conclusion based on the same "size of parameter" argument, and this is the basis for some other test libraries explicitly defining the order as expected, actual.

I didn't give my actual opinion on the topic in my reply, which probably made my point less clear. I don't think assert_eq! should use expected/actual labels in either order, because it seems to me that there is no real consensus (either in Rust or in other languages/libraries) around which order is correct, and explicitly defining the order now is not going to fix that - it's just going to end up with a bunch of code where the labels are backwards. I don't think introducing a new assertion with a different name really fixes this either if it's still possible to switch them in the code without an error, because people will carry over their assumptions about the "right" order from other contexts and still get it wrong.

For some new testing assertion primitive like the matcher-based options mentioned, where the two parameters are not interchangable and switching them will actually fail to compile, that's a different story, but I would assume that anyone defining an intentionally non-symmetrical primitive like this would already be making it produce the desired kind of output that makes it clear what happened.

Discussion in the ATmosphere

Loading comments...