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

Traits for ?? #2019

Closed
jD91mZM2 opened this issue Jun 2, 2017 · 3 comments
Closed

Traits for ?? #2019

jD91mZM2 opened this issue Jun 2, 2017 · 3 comments

Comments

@jD91mZM2
Copy link

jD91mZM2 commented Jun 2, 2017

I sadly barely get to use ?, because I find myself not using Result<> as often because it just doesn't fit in. For example, I instead return a struct with a success boolean at one point, or I wanna completely ignore errors the other. There should be a way for ? to detect return values and use some trait to return an error.

For example:

struct Stuff {
    // some fields here
    success: bool
}

impl Try for Stuff {
    fn err(error: std::error::Error) -> Stuff {
        Stuff{
            // some fields here
            success: false;
        }
    }
}

Also, () return values would implement the trait as well, but return.. well... nothing.

If the suggestion sounds stupid to you - sorry for disturbing :(

@pnkfelix
Copy link
Member

pnkfelix commented Jun 2, 2017

Can you clarify how your suggestion differs from existing (and accepted) RFC #1859, text here

@burdges
Copy link

burdges commented Jun 2, 2017

Your examples sound like they map to Result easily enough. There are methods like map_err and ok_or on Result and Option for most issues that you might encounter.

If you want to find examples that do not always fit Result so well, then you should look at futures and the discussions around futures in the ? rfcs and tracking issues. In other words, your code returns a three+ state enum where what counts as an error may shift depending on usage, so maybe one needs some extra-ergonomic error mapping methods.

@jD91mZM2
Copy link
Author

jD91mZM2 commented Jun 2, 2017

@pnkfelix is right. It's no different from that pull request.

@jD91mZM2 jD91mZM2 closed this as completed Jun 2, 2017
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

No branches or pull requests

3 participants