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

1

This was briefly discussed here although with a wildcard of requested implementations Impls of TryFrom · Issue #50212 · rust-lang/rust · GitHub 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.

2

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.

1 Like
3

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.

4

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.

5

Parsing floats is…complicated. There are entire crates 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).

6

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

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

7

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

1 Like