# \`TryFrom\<&str\>\` implementations for all types currently implementing \`FromStr\`

**URL:** https://internals.rust-lang.org/t/tryfrom-str-implementations-for-all-types-currently-implementing-fromstr/21936
**Category:** Uncategorized
**Created:** [November 29, 2024, 11:30am UTC](https://internals.rust-lang.org/t/tryfrom-str-implementations-for-all-types-currently-implementing-fromstr/21936 "2024-11-29T11:30:56Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![andrewbaxter](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/andrewbaxter/32/12186_2.png) [@andrewbaxter](https://internals.rust-lang.org/u/andrewbaxter)
#### Post date: [November 29, 2024, 11:30am UTC](https://internals.rust-lang.org/t/tryfrom-str-implementations-for-all-types-currently-implementing-fromstr/21936/1 "2024-11-29T11:30:56Z")

</div>

This was briefly discussed here although with a wildcard of requested implementations [Impls of TryFrom · Issue #50212 · rust-lang/rust · GitHub](https://github.com/rust-lang/rust/issues/50212) with the suggestion of making issues for specific implementations. It looks like the processes have changed since (?), so I'm posting here as instructed by the github issue submission templates.

Although that might not have been the meaning, my request is specific: all types currently implementing `FromStr` in the current library.

`FromStr` is currently used as a compatibility baseline for various text parsing libraries (for instance command line parsing, query string parsing, regex parsing). But because it doesn't expose the lifetime parameter, all non-transformative implementations must allocate.

AFAIK `TryFrom` was at least in part intended as a replacement for `FromStr`, but also AFAIK none of the basic types in the library implement it whereas they do implement `FromStr`.

The primary objection from the original issue is that the interface is too simple whereas parsing can be very complex and need more nuanced control or be context-specific (if I understand correctly). My response is:

1. Some parsing is very simple, or there's an obvious default parsing, or there's a canonical string parsing. For instance I can't think of any other reasonable representations for `f32` other than `\d+(.\d*)?` and a `from_str`-like method works great
2. If more nuanced parsing is required, that can just be a separate non-trait (i.e. non-standardized) method. Like `u32` has `from_str_radix` which coexists with `from_str`.
3. This seems like as much an objection to `FromStr` as to `TryFrom<&str>`, and I'm not aware of significant issues with the former. From consistency standpoint, I don't believe this should be rejected on those grounds.

There might be an objection that this shouldn't be in the standard library but in a 3rd party library. Implementations of `TryFrom` must be in the standard library to be implemented for base types. A new 3rd party crate could be made with a new `TryFrom` trait, but it would be DOA trying to compete with `TryFrom` which has the authority of the standard library.

---

<div class="post-metadata">

### Author: ![mathstuf](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@mathstuf](https://internals.rust-lang.org/u/mathstuf)
#### Post date: [November 29, 2024, 12:57pm UTC](https://internals.rust-lang.org/t/tryfrom-str-implementations-for-all-types-currently-implementing-fromstr/21936/2 "2024-11-29T12:57:18Z")

</div>

> [@andrewbaxter](#):
>
> For instance I can't think of any other reasonable representations for `f32` other than `\d+(.\d*)?` and a `from_str`-like method works great

FYI, parsing exponents and negation are missing from here. I'm sure there's another example you can provide here, but `f32` isn't quite so simple.

---

<div class="post-metadata">

### Author: ![andrewbaxter](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/andrewbaxter/32/12186_2.png) [@andrewbaxter](https://internals.rust-lang.org/u/andrewbaxter)
#### Post date: [November 29, 2024, 1:05pm UTC](https://internals.rust-lang.org/t/tryfrom-str-implementations-for-all-types-currently-implementing-fromstr/21936/3 "2024-11-29T13:05:00Z")

</div>

Thanks, you're right. I just meant that to visualize the sort of format it'd handle, I doubt it's using a regex under the hood either. In reality, I'd expect the implementation to be the same as `from_str`.

---

<div class="post-metadata">

### Author: ![jdahlstrom](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jdahlstrom/32/3351_2.png) [@jdahlstrom](https://internals.rust-lang.org/u/jdahlstrom)
#### Post date: [November 29, 2024, 1:10pm UTC](https://internals.rust-lang.org/t/tryfrom-str-implementations-for-all-types-currently-implementing-fromstr/21936/4 "2024-11-29T13:10:01Z")

</div>

Also whether NaNs and infinities should be supported. And then there's obviously decimal separator, thousands separator, and so on – although it's a design decision that `FromStr` only supports the "C locale", it's still a choice you have to make and by no means "obvious" or "the only reasonable" representation.

---

<div class="post-metadata">

### Author: ![mathstuf](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@mathstuf](https://internals.rust-lang.org/u/mathstuf)
#### Post date: [November 29, 2024, 1:12pm UTC](https://internals.rust-lang.org/t/tryfrom-str-implementations-for-all-types-currently-implementing-fromstr/21936/5 "2024-11-29T13:12:58Z")

</div>

Parsing floats is…complicated. There are [entire crates](https://lib.rs/crates/ryu) dedicated to it and long-standing bugs in reference implementations copied around since the 60s or so (maybe it was `printf`? having trouble surfacing a reference right now).

---

<div class="post-metadata">

### Author: ![andrewbaxter](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/andrewbaxter/32/12186_2.png) [@andrewbaxter](https://internals.rust-lang.org/u/andrewbaxter)
#### Post date: [November 29, 2024, 1:32pm UTC](https://internals.rust-lang.org/t/tryfrom-str-implementations-for-all-types-currently-implementing-fromstr/21936/6 "2024-11-29T13:32:20Z")

</div>

Okay, my bad - I truly didn't mean to dig up any traumatic experiences here with my choice of example 😅

`s/f32/u32/g` (don't tell me the history of decimal integer parsing is similarly colorful)

---

<div class="post-metadata">

### Author: ![mathstuf](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@mathstuf](https://internals.rust-lang.org/u/mathstuf)
#### Post date: [November 29, 2024, 2:09pm UTC](https://internals.rust-lang.org/t/tryfrom-str-implementations-for-all-types-currently-implementing-fromstr/21936/7 "2024-11-29T14:09:14Z")

</div>

No hard feelings; if it was that traumatic I'd have a link to that reference-impl bug on hand 😃 . I more just enjoy finding corner cases and IEEE754 has…many. Also interested in helping improve suggestions to Rust overall.

---

<div class="post-metadata">

### Author: ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)
#### Post date: [May 23, 2026, 2:09pm UTC](https://internals.rust-lang.org/t/tryfrom-str-implementations-for-all-types-currently-implementing-fromstr/21936/8 "2026-05-23T14:09:31Z")

</div>

This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.
