Code
use std::ops::Add;
fn foo() -> impl Add<u32> {
unimplemented!()
}
fn main() {}Current output
error[E0277]: cannot add `u32` to `!`
--> src/main.rs:3:13
|
3 | fn foo() -> impl Add<u32> {
| ^^^^^^^^^^^^^ no implementation for `! + u32`
4 | unimplemented!()
| ---------------- return type was inferred to be `!` here
|
= help: the trait `Add<u32>` is not implemented for `!`
Desired output
A hint or suggestion should be added which explains that casting to a a concrete type which implements the given trait (for example, unimplemented!() as u32) will resolve the error, given that ! can be coerced into any concrete type.
Rationale and extra context
While the unimplemented! and todo! macros are usually temporary in code, using them to mock APIs is a common use case, such as allowing tests to typecheck or to write an API shape before writing the implementation.
When such a mocked function returns impl Trait, the compiler error makes it seem like it's not possible to leave these functions unimplemented. However, casting to a concrete type which implements Trait is a simple workaround that is also non-obvious.
Other cases
Rust Version
rustc 1.96.0 (ac68faa20 2026-05-25)
binary: rustc
commit-hash: ac68faa20c58cbccd01ee7208bf3b6e93a7d7f96
commit-date: 2026-05-25
host: x86_64-unknown-linux-gnu
release: 1.96.0
LLVM version: 22.1.2
Anything else?
Related to #36375 and #113875
Code
Current output
Desired output
A hint or suggestion should be added which explains that casting to a a concrete type which implements the given trait (for example,
unimplemented!() as u32) will resolve the error, given that!can be coerced into any concrete type.Rationale and extra context
While the
unimplemented!andtodo!macros are usually temporary in code, using them to mock APIs is a common use case, such as allowing tests to typecheck or to write an API shape before writing the implementation.When such a mocked function returns
impl Trait, the compiler error makes it seem like it's not possible to leave these functions unimplemented. However, casting to a concrete type which implementsTraitis a simple workaround that is also non-obvious.Other cases
Rust Version
Anything else?
Related to #36375 and #113875