Tracking issue for RFC 1866: More readable assert_eq

[aturon]

This is a tracking issue for the RFC "More readable assert_eq" (rust-lang/rfcs#1866).

Steps:

• Implement the RFC (assert_eq failure message easier to read #42541)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

• Should we also cover assert_ne?
• Should we incorporate color support, or use LLVM-style arrows?

[colin-kiegel]

• IMO assert_ne should also print multi-lines, but not show a diff
• Color support in the built-in assert_eq! would be awesome. :-)

small side-note: In case anyone wants to use this before it is stabilized, I just implemented multiline display in pretty_assertions (v0.2) and it currently looks like this:

[golddranks]

Btw. red and green aren't maybe the best choices for colour coding, as the red-green colour blindness is the most common type of vision deficiency out there. (The coloured pieces would still stand out from the normal text if I understand red-green-colour blindness correctly, but not from each others.)

[colin-kiegel]

git diff --word-diff does the following by default

The quick brown [-duck-]{+fox+} jumps over the lazy dog

Where [-duck-] and {+fox+} are colored red/green if the terminal supports it. This is also readable without color support (or color blindness). However this might be ambiguous if the underlying text already contains such character sequences.

[ordovicia]

Is this tracking issue supposed to be closed?

[kennytm]

Thanks @ordovicia.

I've reopened the issue since there are still two unresolved questions (color and arrow).

However AFAIK there can be no "Stabilization PR", the change is insta-stable. For "Adjust documentation", perhaps check the books if the output format needs to be updated, but otherwise no specific documentation is needed for this feature.