Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for TryFrom/TryInto traits #33417

Closed
alexcrichton opened this issue May 4, 2016 · 240 comments
Closed

Tracking issue for TryFrom/TryInto traits #33417

alexcrichton opened this issue May 4, 2016 · 240 comments

Comments

@alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented May 4, 2016

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
sfackler added a commit to sfackler/rust that referenced this issue May 5, 2016
sfackler added a commit to sfackler/rust that referenced this issue May 5, 2016
sfackler added a commit to sfackler/rust that referenced this issue May 7, 2016
Manishearth added a commit to Manishearth/rust that referenced this issue May 8, 2016
Manishearth added a commit to Manishearth/rust that referenced this issue May 8, 2016
Implement RFC 1542

cc rust-lang#33417

r? @aturon
Manishearth added a commit to Manishearth/rust that referenced this issue May 8, 2016
Implement RFC 1542

cc rust-lang#33417

r? @aturon
@Zoxc
Copy link
Contributor

@Zoxc Zoxc commented May 9, 2016

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
Copy link
Member

@chris-morgan chris-morgan commented May 10, 2016

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

@shepmaster
Copy link
Member

@shepmaster shepmaster commented Jul 9, 2016

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 sfackler added the I-nominated label Jul 9, 2016
@sfackler
Copy link
Member

@sfackler sfackler commented Jul 9, 2016

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

@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jul 13, 2016

🔔 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
Copy link
Contributor

@ollie27 ollie27 commented Jul 14, 2016

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
Copy link
Member Author

@alexcrichton alexcrichton commented Jul 14, 2016

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

@sfackler
Copy link
Member

@sfackler sfackler commented Jul 15, 2016

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
Copy link
Contributor

@SimonSapin SimonSapin commented Jul 15, 2016

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
Copy link
Member

@sfackler sfackler commented Jul 15, 2016

@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
Copy link
Contributor

@glaebhoerl glaebhoerl commented Jul 15, 2016

@Ericson2314
Copy link
Contributor

@Ericson2314 Ericson2314 commented Jul 15, 2016

@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
Copy link
Contributor

@ollie27 ollie27 commented Jul 16, 2016

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
Copy link
Contributor

@malbarbo malbarbo commented Jul 27, 2016

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

@RustyYato
Copy link
Contributor

@RustyYato RustyYato commented Feb 25, 2019

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.

bors added a commit that referenced this issue Feb 25, 2019
Stabilize TryFrom and TryInto with a convert::Infallible empty enum

This is the plan proposed in #33417 (comment)
bors added a commit that referenced this issue Feb 25, 2019
Stabilize TryFrom and TryInto with a convert::Infallible empty enum

This is the plan proposed in #33417 (comment)
Centril added a commit to Centril/rust that referenced this issue Feb 28, 2019
Expand docs for `TryFrom` and `TryInto`.

The examples are still lacking for now, both for module docs and for methods/impl's.  Will be adding those in further pushes.

Should hopefully resolve the doc concern in rust-lang#33417 when finished?
Centril added a commit to Centril/rust that referenced this issue Feb 28, 2019
Expand docs for `TryFrom` and `TryInto`.

The examples are still lacking for now, both for module docs and for methods/impl's.  Will be adding those in further pushes.

Should hopefully resolve the doc concern in rust-lang#33417 when finished?
@bartsmykla
Copy link

@bartsmykla bartsmykla commented Mar 12, 2019

How can I help with documentation? :-)

@SimonSapin
Copy link
Contributor

@SimonSapin SimonSapin commented Mar 12, 2019

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

bors added a commit that referenced this issue Mar 12, 2019
Expand docs for `TryFrom` and `TryInto`.

The examples are still lacking for now, both for module docs and for methods/impl's.  Will be adding those in further pushes.

Should hopefully resolve the doc concern in #33417 when finished?
@o01eg
Copy link
Contributor

@o01eg o01eg commented Mar 30, 2019

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

fn check(value: &T) -> bool
@Kerollmops
Copy link
Contributor

@Kerollmops Kerollmops commented Mar 30, 2019

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

@SimonSapin
Copy link
Contributor

@SimonSapin SimonSapin commented Apr 9, 2019

Oops this should have been closed by #58302. Closing now.


@o01eg The typical way to do non-consuming conversion is to implement e.g. TryFrom<&'_ Foo> instead of TryFrom<Foo>.

@SimonSapin SimonSapin closed this Apr 9, 2019
@ErichDonGubler
Copy link

@ErichDonGubler ErichDonGubler commented Apr 9, 2019

Wait...this shouldn't actually close until landing on stable Thursday, right?

@sfackler
Copy link
Member

@sfackler sfackler commented Apr 9, 2019

No, we close tracking issues when the PR stabilizing the feature lands on master.

@SimonSapin
Copy link
Contributor

@SimonSapin SimonSapin commented Apr 9, 2019

No, we usually close tracking issue when the stabilization or removal lands in the master branch. After that there is nothing left to track. (Unless a newly-reported bug comes up, but we handle that separately.)

@jethrogb
Copy link
Contributor

@jethrogb jethrogb commented Apr 9, 2019

Tracking issues are closed by the PR that stabilizes them. Depending on the release cycle, this could be up to 12 weeks before stable is released.

@ErichDonGubler
Copy link

@ErichDonGubler ErichDonGubler commented Apr 9, 2019

Got it. Thanks for the clarification, everyone! :)

@shepmaster
Copy link
Member

@shepmaster shepmaster commented Jun 5, 2019

@gregdegruy update your version of Rust to 1.34 or higher.

bors bot added a commit to rust-itertools/itertools that referenced this issue Oct 1, 2019
Merge #327
327: Either crate style methods for EitherOrBoth r=jswrenn a=Avi-D-coder

I have recently been using `zip_longest`. Without Functors or lens it's a bit of a pain. 
@bluss's [either crate](https://crates.io/crates/either) has methods to make dealing with either variants nicer, so I added some of them. I attempted to make the naming and implementation as similar as possible, but there are a few differences.

A fallible method of converting `EitherOrBoth` into an `either` would be very useful providing exclusive (not including `Both` variant) methods. Converting should probably wait for rust-lang/rust#33417.

Co-authored-by: Avi ד <avi.the.coder@gmail.com>
daniel-ferguson added a commit to daniel-ferguson/hi that referenced this issue Feb 7, 2020
We enable the "nightly" feature to get better error messages. Nightly
is needed to build this project anyway until `TryFrom` lands [RFC],
[tracking issue].

[1]: https://github.com/Geal/nom
[RFC]: https://github.com/tbu-/rust-rfcs/blob/a4a22d7c5dd71724bb2cd0fe2db5026338d0b270/text/1542-try-from.md
[tracking issue]: rust-lang/rust#33417
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.