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

Different error messages between async and regular functions #63277

Closed
Patryk27 opened this issue Aug 5, 2019 · 2 comments
Closed

Different error messages between async and regular functions #63277

Patryk27 opened this issue Aug 5, 2019 · 2 comments

Comments

@Patryk27
Copy link
Contributor

@Patryk27 Patryk27 commented Aug 5, 2019

Hi,

Let's consider following code:

fn foo() -> Result<bool, ()> {
    unimplemented!()
}

fn bar() -> Result<(), ()> {
    foo()?;
    ()
}

There's an error in the penultimate line - it should say Ok(()) and Rust correctly helps to spot the mistake:

  |
7 | fn bar() -> Result<(), ()> {
  |             -------------- expected `std::result::Result<(), ()>` because of return type
8 |     foo()?;
9 |     ()
  |     ^^ expected enum `std::result::Result`, found ()
  |
  = note: expected type `std::result::Result<(), ()>`
             found type `()`

The situation changes a bit when we switch to async functions:

#![feature(async_await)]

async fn foo() -> Result<bool, ()> {
    unimplemented!()
}

async fn bar() -> Result<(), ()> {
    foo().await?;
    ()
}

The error message now says the '?' operator can only be used in a function that returns 'Result' or 'Option', which is totally unhelpful, since the function is (or at least should be) returning a Result, according to its signature.

It seems that, when dispatching error messages, the actual return types have precedence over signatures in async functions, but it's exactly the other way around in regular functions, which leads to kinda unexpected and confusing error messages.

@Patryk27
Copy link
Contributor Author

@Patryk27 Patryk27 commented Aug 5, 2019

For reference, it seems it's a duplicate of: #54326.

Loading

@cramertj
Copy link
Member

@cramertj cramertj commented Aug 5, 2019

Closing as duplicate.

Loading

@cramertj cramertj closed this Aug 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants