Tracking issue for TryFrom/TryInto traits

[alexcrichton]

Tracking issue for rust-lang/rfcs#1542

---

To do:

• Is existing documentation satisfactory?
• #56796 Change bounds on TryFrom blanket impl to use Into instead of From
• (Re)stabilization PR

[Zoxc]

Is there a way to generically print an error with the original value if the conversion fails without requiring Clone so a related method which panics on failure could have nice error messages?

[chris-morgan]

A discussion of whether this should go in the prelude is pending for when this goes stable.

[shepmaster]

Apologies if this is covered somewhere else, but what would we like to see before marking this as stable? I'm pretty sure I've reimplemented this functionality a few times in various projects, so a common reusable trait would make me 😄

[sfackler]

We can bring it up for discussion for the next cycle.

[alexcrichton]

🔔 This issue is now entering a cycle-long final comment period for stabilization 🔔

As a point of stabilization, the libs team would also like to add these traits to the prelude as part of their stabilization. This will require a crater run being 100% clean at minimum, but we're relatively confident that the current state of resolve makes it backwards compatible to add traits to the prelude.

[ollie27]

I have a few questions about the purpose of these traits.

1. Which types in std will these be implemented for?
2. Which types should get implementations like impl TryFrom<T> for T?
3. Which types should get implementations like impl TryFrom<U> for T if they already have impl From<U> for T?

[alexcrichton]

cc @sfackler, could you expand on the current set of impls and some of the rationale as well?

[sfackler]

I think in general the intuition should be exactly the same for that of From/Into, except when the conversion can fail. Just like we gradually add implementations of From and Into to standard library types, I expect we'll do the same for TryFrom and TryInto. The most important guideline here is that the conversion should be the "canonically obvious" one - if there's more than one reasonable way to convert one type to another, TryFrom or From may not be the right things to use.

In general, I don't think it should be expected that all types should impl TryFrom<T> for T or manually lift an impl From<U> for T. In particular, it's often not clear which error type to pick. However, those kinds of implementations are very much ones that can and should be defined to make a particular API work. For example, we have both of these kinds of implementations for various combinations of primitive integer types for the reasons outlined in the RFC. As another example, one ad-hoc trait that TryFrom/TryInto will replace is postgres::IntoConnectParams, which has a reflexive implementation to convert a ConnectParams into itself.

[SimonSapin]

In general, I don't think it should be expected that all types should impl TryFrom<T> for T or manually lift an impl From<U> for T.

When a TryFrom conversion happens to be infallible the error type should be enum Void {}, right? (Or a similar enum with some other name.) Which by the way sounds to me like a good reason to have a general purpose Void type in std.

[sfackler]

@SimonSapin that would break an IntoConnectParams style API as well as the integer conversion use case outlined in the RFC since the error types of the infallible and fallible conversions wouldn't match.

[glaebhoerl]

@SimonSapin rust-lang/rfcs#1216

[Ericson2314]

@sfackler Not if you use plain From for the error types(e.g. try!)! impl<T> From<!> for T can and should exist for that purpose.

[ollie27]

Just like we gradually add implementations of From and Into to standard library types, I expect we'll do the same for TryFrom and TryInto.

That doesn't appear to have happened yet so I don't know if it's because nobody has got round to it or there are no applicable types in std. If there are applicable types in std it would be nice to see some implementations for them. For example are any of the following good implementations?

impl TryFrom<u32> for char
impl TryFrom<char> for u8
impl TryFrom<Vec<u8>> for String
impl TryFrom<&[u8]> for &str

In general, I don't think it should be expected that all types should impl TryFrom<T> for T or manually lift an impl From<U> for T.

The issue is that if you want to use TryInto<T> and T isn't in your crate then you have to just hope that impl TryFrom<T> for T has been implemented. That's an unfortunate limitation, one which doesn't exist for From/Into.

@SimonSapin that would break an IntoConnectParams style API as well as the integer conversion use case outlined in the RFC since the error types of the infallible and fallible conversions wouldn't match.

Does this mean the error type is somehow fixed based on the type you're converting to?

[malbarbo]

Why TryFrom::Err and TryInto::Err is not bounded by std::error::Error?

[marco9999]

Sorry if this is the wrong place, but looks like there is a mistake in the docs for TryFromIntError - it lists impl Debug for TryFromIntError, when actually there is no code for it. The compiler generates an error currently when trying to unwrap a result from a TryFrom usage.

Is there meant to be a fmt::Debug impl on this?

[lnicola]

@marco9999

#[derive(Debug, Copy, Clone, PartialEq, Eq)]
pub struct TryFromIntError(());

It's got a #[derive(Debug)] attribute.

[marco9999]

Hmm yea there is... is something not working properly?

error[E0599]: no method named `unwrap` found for type `std::result::Result<usize, <T as std::convert::TryInto<usize>>::Error>` in the current scope
  --> src\types\b8_memory_mapper.rs:67:51
   |
67 |         let address: usize = T::try_into(address).unwrap();
   |                                                   ^^^^^^
   |
   = note: the method `unwrap` exists but the following trait bounds were not satisfied:
           `<T as std::convert::TryInto<usize>>::Error : std::fmt::Debug`

[lnicola]

@marco9999 You're probably missing a generic constraint. TryFromIntError is only used by some types, but your T could be anything:

fn foo<T: TryInto<u8>>(x: T) -> u8
where
    <T as TryInto<u8>>::Error: Debug,
{
    x.try_into().unwrap()
}

Anyway, this is a bit out of topic, sorry everyone. IRC might be a better place to ask these questions.

[shepmaster]

I want to assert_eq!(some_value, std::num::TryFromIntError(()));

@icefoxen There's no useful value associated with TryFromIntError so such an assertion doesn't seem to have much value. If you have a Result<_, TryFromIntError> and it's an Err, there's no other value it could be.

assert!(some_value_result.is_err());

This seems reasonable to me.

[glaebhoerl]

Cross-referencing: #58302

[SimonSapin]

Thanks @glaebhoerl.

Due to a blocking bug being fixed (#49593) I was hoping that the never type could be stabilized Soon® #57012 and unblock this. However a new issue (#57012 (comment)) has come up, and we also don’t have consensus on another one (#57012 (comment)).

So in a libs meeting last week I brought up again the idea, I believe first proposed by @scottmcm in #33417 (comment), to stabilize TryFrom and TryInto without the never type, and instead have an empty enum that could later be made an alias to !.

Last time we discussed this (#33417 (comment)), we couldn’t remember why we hadn’t done this the previous time.

Last week @dtolnay reminded us of the issue: before ! becomes a full type, it can already be used in place of the return type of a function to indicates that it never returns. This includes function pointer types. So, assuming #58302 lands in this cycle, code like this will be valid in Rust 1.34.0:

use std::convert::Infallible;
trait MyTrait {}
impl MyTrait for fn() -> ! {}
impl MyTrait for fn() -> Infallible {}

Because fn() -> ! and fn() -> Infallible are two different (pointer) types, the two impls do not overlap. But if we replace the empty enum with a pub type Infallible = !; type alias (when ! becomes a full type), then the two impls will start to overlap and code like the above will break.

So changing the enum to an alias would be a breaking change. On principle we wouldn’t allow it in the standard library, but in this case we felt that:

• One has to go out of their way to build code that is broken by this change, so it seems unlikely to happen in practice
• We’ll use Crater to get additional signal when the time come
• If we end up judging the breakage to be significant enough, having both the never type and an empty enum with the same role is an inconsistency we can live with.

Based on this discussion, I submitted #58302 which is now in Final Comment Period.

[icefoxen]

#58015 should be ready for review/merge now.

[xfix]

@kennytm Isn't it possible to refer to ! in stable already? For instance, consider the following:

trait MyTrait {
    type Output;
}

impl<T> MyTrait for fn() -> T {
    type Output = T;
}

type Void = <fn() -> ! as MyTrait>::Output;

After doing this, Void refers to ! type.

[KrishnaSannasi]

That looks like a bug, which means stability guarantees don't extend to it. Using the never type (!) as a type in any capacity is still unstable, at least until #57012 is merged.

[bartsmykla]

How can I help with documentation? :-)

[SimonSapin]

Oh I thought #58015 had landed, but it hasn’t yet… Let’s discuss it there.

[o01eg]

Could TryFrom trait have a method to check if argument could be converted without consuming it?

fn check(value: &T) -> bool

[Kerollmops]

One way to work with non-consuming impossible conversion could be to return the consumed non-convertible value along with the associated error.