-
Notifications
You must be signed in to change notification settings - Fork 8
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
eq matcher with temporary values #9
Comments
Why not just do this? fn test() {
assert_that!(&S::new(42), eq(&S::new(42)));
assert_that!(&S::new(42), not(eq(&S::new(41))));
} Another approach: #[derive(PartialEq, Debug)]
#[cfg_attr(test, derive(Clone))] // Notice we derive Clone in test builds
struct S {
val: u32
}
impl S {
pub fn new(val: u32) -> Self {
S { val }
}
}
#[test]
fn test() {
let s = S::new(42);
assert_that!(s.clone(), eq(S::new(42)));
assert_that!(s.clone(), not(eq(S::new(41))));
} We did have support for auto-unwrapping references, but it had to be reverted because the way it was implemented broke backwards compatibility. Still looking for a way to implement that (PRs welcome, I'm out of ideas :)). |
The first solution id a variant of (3) and fails because of a dropped temporary value. You probably meant:
which works, yet it is harder to read (from my point of view). Working and more concise (but also misleading in my opinion):
Using I had several ideas, maybe you have tried some of them:
|
I think the variant with calls to clone is fine and pretty readable. Anyone familiar with Rust will be familiar with what
That's my current train of thought as well. |
Yet my idea will conflict with backward compatibility, however my thoughts about this: What is more intuitive when asserting a statement on some argument:
I would vote for 2. Talking about an object does not affect its state is more like borrowing than consuming. Maybe an idea for the next major version? |
I would strongly support this, I realise this is an old issue request now and maybe this repo isn't being maintained. The workarounds suggested don't always work, if something isn't cloneable for example and taking references often gives the |
I am not certain how to succintly express an assert in following context (shortened, abstract example):
Assume following context:
The test (1):
will not compile because s is consumed in the first assert statement.
The test (2):
will not compile because the eq-matcher does not support unwrapping references.
The test (3):
will not compile with 'temporary value dropped while borrowed'.
I could fix test (3) by introducing temporary variables, yet the test gets quite ugly with temporary variables.
My questions:
Is there another solution to test what I expect?
Is it planned to support something similar to test (2)?
The text was updated successfully, but these errors were encountered: