Allow error type conversions in ensure! and ensure_eq! #474
Conversation
| } | ||
|
|
||
| #[test] | ||
| fn ensure_can_infer_error_type() { |
There was a problem hiding this comment.
I'd love to understand why this works. How does Rust infer the error type in that case?
There was a problem hiding this comment.
Woah, this compiles???
I guess it uses the matches! segment to determine it is expected to compare with StdError, thus setting the Result<_, StdError>. But this compiler is starting to get a bit too smart....
| if $a != $b { | ||
| return Err($e); | ||
| } | ||
| ensure!($a == $b, $e); |
| } | ||
|
|
||
| #[test] | ||
| fn ensure_can_infer_error_type() { |
There was a problem hiding this comment.
Woah, this compiles???
I guess it uses the matches! segment to determine it is expected to compare with StdError, thus setting the Result<_, StdError>. But this compiler is starting to get a bit too smart....
| #[derive(Debug)] | ||
| struct ContractError; | ||
|
|
||
| impl From<StdError> for ContractError { |
| } | ||
| } | ||
|
|
||
| fn check(a: usize, b: usize) -> Result<(), ContractError> { |
There was a problem hiding this comment.
Okay, here is the real test of the compiler's intelligence:
If you remove -> Result<(), ContractError>, will the compiler infer it from line 97?
There was a problem hiding this comment.
An fn always needs a specific return type. Unset means (). So this is more realistic that the closure test case.
But yes, if you turn it into a closure and remove the return type, compiler can infer it.
Good point
I'm in favour of removing |
I second that. |
As discussed before.