Tracking issue for TryFrom/TryInto traits #33417

alexcrichton · 2016-05-04T23:28:52Z

Tracking issue for rust-lang/rfcs#1542

To do:

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

The text was updated successfully, but these errors were encountered:

cc rust-lang#33417

@aturon

Implement RFC 1542 cc rust-lang#33417 r? @aturon

@aturon

Implement RFC 1542 cc rust-lang#33417 r? @aturon

Zoxc · 2016-05-09T18:20:53Z

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 · 2016-05-10T05:24:58Z

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

shepmaster · 2016-07-09T13:19:49Z

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 · 2016-07-09T21:24:28Z

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

alexcrichton · 2016-07-13T00:03:47Z

🔔 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 · 2016-07-14T16:07:59Z

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

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

alexcrichton · 2016-07-14T21:27:14Z

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

sfackler · 2016-07-15T13:39:16Z

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 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 · 2016-07-15T14:05:51Z

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 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 · 2016-07-15T14:21:43Z

@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 · 2016-07-15T16:47:59Z

@SimonSapin rust-lang/rfcs#1216

Ericson2314 · 2016-07-15T17:24:52Z

@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 · 2016-07-16T17:16:29Z

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 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 · 2016-07-27T22:20:00Z

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

Stabilize TryFrom and TryInto with a convert::Infallible empty enum This is the plan proposed in #33417 (comment)

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 · 2019-03-12T10:14:14Z

How can I help with documentation? :-)

SimonSapin · 2019-03-12T10:20:28Z

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

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 · 2019-03-30T12:18:34Z

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

fn check(value: &T) -> bool

Kerollmops · 2019-03-30T12:55:45Z

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

SimonSapin · 2019-04-09T06:59:11Z

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

ErichDonGubler · 2019-04-09T16:39:00Z

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

sfackler · 2019-04-09T16:43:43Z

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

SimonSapin · 2019-04-09T16:44:22Z

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 · 2019-04-09T16:44:25Z

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 · 2019-04-09T16:55:56Z

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

shepmaster · 2019-06-05T17:21:12Z

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

@bluss

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 ד <[email protected]>

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

Tracking issue: rust-lang/rust#33417 [git filter-repo] original commit: rust-lang/rust@e53a2a7

alexcrichton added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels May 4, 2016

alexcrichton mentioned this issue May 4, 2016

Add TryFrom and TryInto traits rust-lang/rfcs#1542

Merged

sfackler mentioned this issue May 5, 2016

Implement RFC 1542 #33426

Merged

sfackler added a commit to sfackler/rust that referenced this issue May 7, 2016

Implement RFC 1542

a9779df

cc rust-lang#33417

Manishearth added a commit to Manishearth/rust that referenced this issue May 8, 2016

Rollup merge of rust-lang#33426 - sfackler:try-from, r=aturon

3f6d7c1

Implement RFC 1542 cc rust-lang#33417 r? @aturon

Manishearth added a commit to Manishearth/rust that referenced this issue May 8, 2016

Rollup merge of rust-lang#33426 - sfackler:try-from, r=aturon

cc98f4c

Implement RFC 1542 cc rust-lang#33417 r? @aturon

oli-obk mentioned this issue May 20, 2016

Numerical Constrained Types rust-lang/rfcs#1621

Open

alexcrichton added B-unstable Blocker: Implemented in the nightly compiler and unstable. and removed B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels Jun 21, 2016

sfackler added the I-nominated label Jul 9, 2016

alexcrichton added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed I-nominated labels Jul 13, 2016

This was referenced Feb 25, 2019

Tracking issue for promoting ! to a type (RFC 1216) #35121

Open

The never type can be named despite its feature gate #58733

Open

bors added a commit that referenced this issue Feb 25, 2019

Auto merge of #58302 - SimonSapin:tryfrom, r=alexcrichton

00aae71

Stabilize TryFrom and TryInto with a convert::Infallible empty enum This is the plan proposed in #33417 (comment)

MauriceKayser mentioned this issue Mar 11, 2019

Add core::convert::TryInto<Primitive> implementation for Expr dtolnay/syn#604

Closed

prasannavl mentioned this issue Apr 2, 2019

add TryFrom impls for path, scheme, uri and authority hyperium/http#308

Closed

SimonSapin closed this as completed Apr 9, 2019

MitMaro mentioned this issue Apr 11, 2019

Use TryFrom trait now that it is stable MitMaro/git-interactive-rebase-tool#104

Merged

hecrj mentioned this issue Jun 13, 2019

error[E0658]: use of unstable library feature 'try_from' (see issue #33417) hecrj/wgpu_glyph#3

Closed

kfogel mentioned this issue Jun 17, 2019

Build fails with "unstable feature" error in rkv dependency phiresky/ripgrep-all#10

Closed

SimonSapin mentioned this issue Oct 14, 2019

Stabilize ! in Rust 1.41.0 #65355

Merged

LukasKalbertodt mentioned this issue Jan 29, 2020

Change FromStr for String to use Infallible directly #67925

Merged

eddyb pushed a commit to LykenSol/rustc_apfloat-git-history-extraction that referenced this issue Nov 14, 2022

Stabilize the TryFrom and TryInto traits

75bc5af

Tracking issue: rust-lang/rust#33417 [git filter-repo] original commit: rust-lang/rust@e53a2a7

Philippe-Cholet mentioned this issue Jan 9, 2024

impl a From instead of an Into rust-itertools/itertools#836

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for TryFrom/TryInto traits #33417

Tracking issue for TryFrom/TryInto traits #33417

alexcrichton commented May 4, 2016 •

edited by SimonSapin

Loading

Zoxc commented May 9, 2016

chris-morgan commented May 10, 2016

shepmaster commented Jul 9, 2016

sfackler commented Jul 9, 2016

alexcrichton commented Jul 13, 2016

ollie27 commented Jul 14, 2016

alexcrichton commented Jul 14, 2016

sfackler commented Jul 15, 2016

SimonSapin commented Jul 15, 2016

sfackler commented Jul 15, 2016

glaebhoerl commented Jul 15, 2016 •

edited

Loading

Ericson2314 commented Jul 15, 2016

ollie27 commented Jul 16, 2016

malbarbo commented Jul 27, 2016

bartsmykla commented Mar 12, 2019

SimonSapin commented Mar 12, 2019

o01eg commented Mar 30, 2019

Kerollmops commented Mar 30, 2019

SimonSapin commented Apr 9, 2019

ErichDonGubler commented Apr 9, 2019

sfackler commented Apr 9, 2019

SimonSapin commented Apr 9, 2019

jethrogb commented Apr 9, 2019

ErichDonGubler commented Apr 9, 2019

shepmaster commented Jun 5, 2019

Tracking issue for TryFrom/TryInto traits #33417

Tracking issue for TryFrom/TryInto traits #33417

Comments

alexcrichton commented May 4, 2016 • edited by SimonSapin Loading

Zoxc commented May 9, 2016

chris-morgan commented May 10, 2016

shepmaster commented Jul 9, 2016

sfackler commented Jul 9, 2016

alexcrichton commented Jul 13, 2016

ollie27 commented Jul 14, 2016

alexcrichton commented Jul 14, 2016

sfackler commented Jul 15, 2016

SimonSapin commented Jul 15, 2016

sfackler commented Jul 15, 2016

glaebhoerl commented Jul 15, 2016 • edited Loading

Ericson2314 commented Jul 15, 2016

ollie27 commented Jul 16, 2016

malbarbo commented Jul 27, 2016

bartsmykla commented Mar 12, 2019

SimonSapin commented Mar 12, 2019

o01eg commented Mar 30, 2019

Kerollmops commented Mar 30, 2019

SimonSapin commented Apr 9, 2019

ErichDonGubler commented Apr 9, 2019

sfackler commented Apr 9, 2019

SimonSapin commented Apr 9, 2019

jethrogb commented Apr 9, 2019

ErichDonGubler commented Apr 9, 2019

shepmaster commented Jun 5, 2019

alexcrichton commented May 4, 2016 •

edited by SimonSapin

Loading

glaebhoerl commented Jul 15, 2016 •

edited

Loading