Add methods for unwrapping Result<T, !> / Result<!, E>

[canndrew]

One of the main intended uses for the ! type is to be able construct the types Result<T, !> and Result<!, E>. Right now, if you have r: Result<T, !> there are several ways to unpack it's inner T, but none of them are ideal:

• r.unwrap(): unwrap is scary and should be avoided. This is also fragile if someone later changes the error type to something other than !.
• r.unwrap_or_else(|e| e): Kinda confusing.
• let Ok(val) = r;: Requires a separate statement. (Also doesn't currently work).
• match r { Ok(v) => v, Err(e) => e }: Both long and kinda confusing.
• match r { Ok(v) => v }: Not as nice as a method on r. (Also doesn't currently work).

The void crate adds the methods void_unwrap and void_unwrap_err to Result<T, Void> and Result<Void, T>. I think methods like these should be added to libcore as well. Perhaps we could call them always_ok() and always_err().

[sfackler]

I like always_* naming-wise.

[glaebhoerl]

Another possibility is if enums where only a single variant is inhabited could have their fields accessed directly, in the same way as structs (which likewise "have a single variant"). So in the case of Result<T, !>, you could access the value simply using .0 (and in the case of enums with "structural variants", using .fieldname). This would presumably have a fix for rust-lang/rust#12609 as a precondition just like the two items in @canndrew's list which don't currently work.

[Stebalien]

I believe we could also just use From/Into:

impl<T> From<Result<T, !>> for T {
    fn from(r: Result<T, !>) -> T {
        r.unwrap()
    }
}

[Sgeo]

@glaebhoerl What if someone changes the type from Result<T, !> to Result<!, T> for some reason? Then .0 continues to work but means something different.

[Stebalien]

@Sgeo

Well, those are different types so that's a breaking change anyways.

[Ericson2314]

For the sake of try! and ?,

impl<T> From<!> for T {
    fn from(r: !) -> T {
        match r { }
    }
}

is my top priority API decision. After that goes whatever else also must also be in stdlib crates to satisfy coherence.

[eddyb]

@Ericson2314 Doesn't that overlap with the identity impl of From?

[Ericson2314]

Uh oh. Any ideas? cause that's a crucial impl.

[Stebalien]

@Ericson2314 not unless we get some way to say where A != B. Feel up for writing an RFC? This is not the same thing as where A: !Trait and doesn't have the same drawbacks (as far as I know at least).

@eddyb Doesn't that overlap with the identity impl of From?

Well..., if we're doing this in core we can use my favorite unstable hack... (although we really shouldn't ever do this):

#![feature(optin_builtin_traits, never_type)]
mod private {
    pub trait NotNever {}
    impl NotNever for .. {}
    impl !NotNever for ! {}
}

trait MyFrom<T> {
    fn from(r: T) -> Self;
}

impl<T> MyFrom<T> for T {
    fn from(r: T) -> T {
        r
    }
}
impl<T: private::NotNever> MyFrom<!> for T {
    fn from(_: !) -> T {
        panic!()
    }
}

[Ericson2314]

@Stebalien that won't work in generic contexts will it?

[Stebalien]

@Ericson2314 It seems to work (gist to avoid polluting this thread with nonsense): https://gist.github.com/85c3af06d9db3a31ba810d9a23792350

Unfortunately, it sets a precedent we can't back out of.

[Ericson2314]

https://is.gd/mU4KWT line 26 fails. I should have been clearer and said I was worried the above wouldn't be as useful due to parametricitiy and a lack of or constraints.

Intriguingly, try! and ? already work, however.

[Stebalien]

Ah 💩. Good point. (My favorite trick failed me 😿)

[Ericson2314]

I mean, now that specialization is here, we don't care about parametricity any more, right? :P