-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Confusing mismatched type error (part 2) #48136
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
Comments
pietroalbini
added
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
A-diagnostics
Area: Messages for errors, warnings, and lints
labels
Feb 11, 2018
Centril
added a commit
to Centril/rust
that referenced
this issue
Dec 23, 2018
Point to cause of `fn` expected return type Fix rust-lang#48136.
Centril
added a commit
to Centril/rust
that referenced
this issue
Dec 23, 2018
Point to cause of `fn` expected return type Fix rust-lang#48136.
Centril
added a commit
to Centril/rust
that referenced
this issue
Dec 23, 2018
Point to cause of `fn` expected return type Fix rust-lang#48136.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
Related to (but different from) #43608.
If you have a function whose return type uses impl trait, you can get confusing type inference errors. The following code...
...produces the following error:
In a much more complicated and less obvious instance of this issue, I spent a long time trying to figure out why the compiler thought that
impl std::fmt::Debug
implied that my return value had to be()
. It would be very helpful if the compiler could say something like "expected type()
because of this line" and point to the originalreturn
(or whatever line caused the inference).Without impl trait, the issue is less prominent because the types must match exactly, and as a result, if the two different return values have different types, at least one of them must fail to match the stated return type in the function declaration. Consider, for example, the following code:
which gives the following error:
The issue with impl trait is that both return values might implement the trait (in this case, both
()
and&'static str
implementDebug
), and so you don't get the same useful messages that you would with a concrete return type.The text was updated successfully, but these errors were encountered: