impl Fail for NoneError?

[Celti]

Using the currently (but probably not for very much longer) unstable Try trait, one can use the question mark operator on Option<T> types, coercing them into a Result<T, NoneError>. Unfortunately, NoneError does not impl std::error::Error, meaning the Fail is not implemented for NoneError (and it being an external type, we can't implement it in our own crates).

I think this would be particularly useful in light of the pattern described in “Using the Error type” — throwing a NoneError fits right into the kind of rapid prototyping, "just show the user the error and exit" limited error handling that that exemplifies.

Would a PR with this change go amiss?

[Celti]

Oh, blast. I just realised this isn't actually possible, because NoneError doesn't implement Display (or in fact anything besides a stack of derives) — which Fail of course requires. Will have to go upstream to see if we can get std::error::Error implemented for NoneError.

[Emilgardis]

Why is this closed? This is something that I really want, and something other users of this crate will want.

[vitvakatu]

Yep, I'm voting for re-opening

[Celti]

As stated in the comment where I closed it, this isn't technically possible — implementing Fail requires an implementation of Display, which NoneError does not currently have. The change will have to happen, and is happening, upstream. You'll just have to wait a while.

[Emilgardis]

Then this issue should track that progress.

[Emilgardis]

FWIW Here are all the related links
rust-lang/rust#31436 (tracking for ´?´)
rust-lang/rust#42526 (impl Try for Option)

As far I can see, unlike @Celti mentioned, there haven't been any discussion about making std::option::NoneError: std::error::Error or Display , could you link that for us?

[withoutboats]

Implementing Fail for NoneError would be an orphan rules violation because of the blanket impls for type that implement std::error::Error (this is also why Fail is not implemented for String, for example). There's no progress that can be made on this issue in failure, only in std.

[dvdplm]

@withoutboats Thank you for weighing in. Do you think making the necessary changes in std for this to happen is a good idea or are there hidden downsides?

[kammoh]

What is the current state regarding this issue?

[aweinstock314]

This workaround requires using foo.unwrap_fail()? instead of just foo?, but was sufficient for my use case:

/// https://github.com/rust-lang-nursery/failure/issues/59
mod workaround_failure_issue_59 {
    #[derive(Debug, Fail)]
    #[fail(display = "NoneError")]
    pub struct NoneError;

    pub trait OptionExt {
        type T;
        fn unwrap_fail(self) -> Result<Self::T, NoneError>;
    }

    impl<U> OptionExt for Option<U> {
        type T = U;
        fn unwrap_fail(self) -> Result<U, NoneError> {
            self.ok_or(NoneError)
        }
    }
}
use workaround_failure_issue_59::OptionExt;