Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Smart assert" that prints the values involved in simple cases #2100

Open
eira-fransham opened this issue Aug 8, 2017 · 4 comments
Open
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@eira-fransham
Copy link

eira-fransham commented Aug 8, 2017

It's pretty annoying for a new Rust programmer to have a pretty unhelpful error message when using the default assert! macro in tests or suchlike. They have to know that the "correct" way to do it is to use assert_eq! or assert_ne!, which do print the value of their arguments. I suggest that we extend the default assert! macro to print operands in simple cases, and then fall back to the current behaviour if an explicit message is provided or if the expression is complex.

I actually thought that Python did this already and I was going to use it as precedent, but its default assertion message is even worse than Rust's.

I have a simple implementation of this here, with the message modelled on assert_eq/assert_ne's message.

@oli-obk
Copy link
Contributor

oli-obk commented Aug 10, 2017

Two problems I see with this:

  1. it's a breaking change for types that do not implement Debug (https://play.rust-lang.org/?gist=028f79c439b15094d9495543e80cd55e&version=stable)
  2. it falls back to the old assehttps://play.rust-lang.org/?gist=028f79c439b15094d9495543e80cd55e&version=stablert if the lhs or rhs expression is not a simple tt, e.g. Foo(5) == x

The first one can probably be addressed via specialization (inside the stdlib that is fine)

The second one must be addressed by writing a proc macro, macro_rules simply isn't powerful enough.

@eira-fransham
Copy link
Author

Yeah, 2 is unfortunate. You can see in my example that I have A + B + C, that doesn't print the nicer message. The way I see it this is an incremental improvement - better than the existing situation even if it's not perfect. A user can always fall back to assert_eq!.

@Techcable
Copy link

Groovy calls these 'power asserts. They're very handy, but I worry they'd signifigantly bloat the size of the generated code. Maybe they should only be enabled in debug mode?

@pnkfelix
Copy link
Member

This other RFC (which recently went into final comment period) is probably relevant: #2011

(Also, I want to mention that its pretty easy to override the assert message, e.g. assert!(x > y, "How can x: {} not be greater than y: {}", x, y);; I infer from the issue description that the filer is already aware of the "explicit message" option, but I suspect not everyone is...)

@Centril Centril added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Dec 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

5 participants