Alternatives to TryFrom

help
1

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.

1 Like
2

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".

2 Likes
3

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?

4

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

5

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.

6

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

1 Like
7

That NoneError leak is demonstrated here:
https://github.com/scottmcm/rust/blob/d2edd2c578c76453ca594105c8f7cd161005daac/src/test/ui/try-trait/try-on-option-in-result-method.rs

1 Like
8

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?

9

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.

2 Likes
10

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.

2 Likes
11

Fair enough.

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

12

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.

13

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.