Alternatives to TryFrom

Soni · February 12, 2021, 5:19pm

We don't like how half of TryFrom impls in std just use an None-equivalent but private error type. Like, why are the integer conversions forced to return a dummy struct instead of just returning None?

Our ideal TryFrom would look something like this:

trait TryFrom<T> {
  type Result: Try<Ok=Self>;
  fn try_from(t: T) -> Self::Result;
}

so that the integer conversions can just return Option<Self> instead. Is there a crate that provides a better TryFrom? This would let us personally use Foo::try_from(bar)? instead of Foo::try_from(bar).ok()? which would make our code much cleaner.

mbrubeck · February 12, 2021, 6:12pm

num_traits::cast provides integer conversions traits/functions that return Option.

Like, why are the integer conversions forced to return a dummy struct instead of just returning None?

One benefit: If the error bubbles up to something that logs it, it displays as "out of range integral type conversion attempted".

Soni · February 12, 2021, 6:54pm

But if it's giving you an Option then you can't make it bubble up because converting None to Err is technically not supposed to be possible?

Cerberuser · February 12, 2021, 6:58pm

Well, it is possible, you just have to specify explicitly what error do you want to see.

Soni · February 12, 2021, 7:03pm

With ?, specifically. We know all the "try v2" proposals talk about NoneError leaking so there must be a way to do it, but it was never meant to be possible. But anyway, None doesn't bubble up like Error.

RustyYato · February 12, 2021, 7:11pm

You can use Option::ok_or/ok_or_else to convert the option to a result, then bubble up errors.

cuviper · February 12, 2021, 7:19pm

That NoneError leak is demonstrated here:

github.com

scottmcm/rust/blob/d2edd2c578c76453ca594105c8f7cd161005daac/src/test/ui/try-trait/try-on-option-in-result-method.rs

// check-pass

#![allow(dead_code, unused)]

///! This isn't supposed to work, but it accidentally did, so unfortunately we need to support this.

struct Tricky;

impl<T: std::fmt::Debug> From<T> for Tricky {
    fn from(_: T) -> Tricky { Tricky }
}

fn foo() -> Result<(), Tricky> {
    None?;
    Ok(())
}

fn main() {
    assert!(matches!(foo(), Err(Tricky)));
}

H2CO3 · February 12, 2021, 7:28pm

I'm not sure why this isn't supposed to work. Tricky is constructible from any type, therefore the From::from conversion picks it up naturally in error position. What am I missing?

cuviper · February 12, 2021, 7:31pm

NoneError was a necessary component for the current Try design, but we really only intended to allow Option->Option and Result->Result. The expectation was that keeping NoneError unstable would allow it to be removed later in a new design, but Tricky shows that it's possible to use it abstractly even in stable code. So we're stuck with Option->Result too.

mbrubeck · February 12, 2021, 7:46pm

I was trying to illustrate one minor benefit of using Result over Option for fallible conversions: The library providing the conversion functions can also provide error descriptions that are sometimes useful for logging/debugging purposes.

Of course, there are also many use cases where this particular feature is not relevant.

Soni · February 12, 2021, 7:56pm

Fair enough.

Uh, still, is there any crate that provides a TryFrom trait, but with Try instead of Result?

mbrubeck · February 12, 2021, 8:02pm

For numeric conversions, I still recommend the traits in num_traits::cast since they are already implemented for all primitive numeric types, as well as library types like BigInt and OrderedFloat.