-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Open
Labels
T-libs-apiRelevant to the library API team, which will review and decide on the RFC.Relevant to the library API team, which will review and decide on the RFC.
Description
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 onr
. (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()
.
durka, plietar, cramertj, oli-obk, dhardy and 11 morekennytm, mark-i-m, petrochenkov, hadronized and lucy
Metadata
Metadata
Assignees
Labels
T-libs-apiRelevant to the library API team, which will review and decide on the RFC.Relevant to the library API team, which will review and decide on the RFC.