Skip to content

Remove Ok(()) with .await as end statement #471

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

pickfire
Copy link
Contributor

Make app.listen more ergonomic.

Before

#[async_std::main]
async fn main() -> Result<(), std::io::Error> {
    let mut app = tide::new();
    app.at("/").get(|_| async { Ok("Hello, world!") });
    app.listen("127.0.0.1:8080").await?;
    Ok(())
}

After

#[async_std::main]
async fn main() -> Result<(), std::io::Error> {
    let mut app = tide::new();
    app.at("/").get(|_| async { Ok("Hello, world!") });
    app.listen("127.0.0.1:8080").await
}

Make app.listen more ergonomic.

Before

    #[async_std::main]
    async fn main() -> Result<(), std::io::Error> {
        let mut app = tide::new();
        app.at("/").get(|_| async { Ok("Hello, world!") });
        app.listen("127.0.0.1:8080").await?;
        Ok(())
    }

After

    #[async_std::main]
    async fn main() -> Result<(), std::io::Error> {
        let mut app = tide::new();
        app.at("/").get(|_| async { Ok("Hello, world!") });
        app.listen("127.0.0.1:8080").await
    }
@yoshuawuyts
Copy link
Member

I'm not sure if we should do this -- ? marks where errors come from, and that's worthwhile having even if the result is smaller.

The lang team is exploring options to remove the need for Ok(()) at the end of functions, which I think is what we really want to solve here. Until then I think keeping this as-is may be good enough (and can also serve as an example of where Ok-wrapping could really help).

@pickfire
Copy link
Contributor Author

pickfire commented Apr 27, 2020

The output is Result<(), std::io::Error> which is exactly the same type as app.listen("127.0.0.1:8080").await. I feel like it is easier to read this way since it will exit when there is Err returning from listen.

I don't think it is necessary to use ? here, ? is useful but here it is similar like using return statement; as the last statement, so it may just be better to return the result directly. I personally think ? is useful when propagating errors halfway, note that quite some functions also returns Result directly such as Result::and_then.

Regarding the lang team solving Ok(()) at the end of functions does not matter, I feel like removing ?; and Ok(()) makes it more explicit.

@Licenser
Copy link

Licenser commented May 1, 2020

+1 to the suggestion.

    app.listen("127.0.0.1:8080").await?;
    Ok(())

makes it unclear what app.listen returns, without looking it up in the docs. do I need to consume something there? Is it something important?

    app.listen("127.0.0.1:8080").await

in contrast makes it clear with the context given that it returns an io::Result<()> so there is no data to look for coming form app.listen.

@pickfire
Copy link
Contributor Author

pickfire commented May 1, 2020

Yes, ? does a conversion for the error with From type that may not be implicit, but app.listen("127.0.0.1:8080").await makes it explicit that it returns io::Error.

Edit: The other reason being the cool factor, how cool is it to be able to listen as the last return and it looks quite idiomatic and mind-blown to me.

@Fishrock123
Copy link
Member

Fishrock123 commented May 19, 2020

We should probably look to having a return value of Result<!, std::io::Error> for either tide 1.0 or 2.0, depending on when never stabilizes, as it is the best answer to this issue.

Edit: I realized this morning that would be more on async_std's end.

@goto-bus-stop goto-bus-stop changed the base branch from master to main August 9, 2020 12:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants