{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig6g3kxrvluu77l4bf2prt3fdci2kn7dsuteamut6en4cp6awx5o4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mih5oiedvpx2"
  },
  "path": "/t/change-error-message-of-a-failing-assert-eq/24118#post_20",
  "publishedAt": "2026-04-01T16:25:57.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "mathstuf:\n\n> 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).\n\nRight, 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`.\n\nI 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.\n\nFor 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.",
  "title": "Change error message of a failing `assert_eq!`"
}