I believe that because the “Try” trait has already been stabilized, that I’ve already lost this argument. “Try” is forever associated with error handling in Rust. My prediction is that there will be endless pressure to make Rust more and more “exception handling-like” over time as those new to the language don’t understand why Rust “try” is different from every other languages “try…catch” etc. Maybe I’m wrong, but, that seems like the kind of thing that happens (in my experience).
EDIT: To clarify what I mean by “lost the argument”: It seems that “Try” has already been blessed as the keyword to talk about Rust error handling (because of the try! macro and now the Try trait). It’s probably too late to reverse that momentum and my opinion on the matter is actually of little importance at this point due to, if nothing else, the inertia of decisions already made. I will note though, that the idea of “result/resultof” being the keyword still isn’t entirely ruled out by the existence of the “try” trait as you suggest as the “try” trait pretty much is built around the notion of making things other than Result<T,E> be able to have an interface compatible with Result<T,E> as shown here:
pub trait Try {
type Ok;
type Error;
fn into_result(self) -> Result<Self::Ok, Self::Error>;
fn from_error(v: Self::Error) -> Self;
fn from_ok(v: Self::Ok) -> Self;
}
It seems like this trait when implemented for an arbitrary type has 2 purposes:
- Return an instance of the arbitrary type T when given and OK or ERROR type
- Return a Result<T,E> where T corresponds to the OK type and E corresponds to the Error type
So, anything utilizing the Try trait is effectively yield a Result<T,E> even though it isn’t a Result<T,E> itself. So, the notion that “resultof” or “result” would be a bad keyword because “things other than Result<T,E>” actually doesn’t apply (in my mind).
That being said, “result/resultof” definitely doesn’t seem to be gaining any traction, so, I’ll yield the floor to anyone with better ideas.
