Guideline for which types need a FromStr impl

[dtolnay]

Some types should have Display but not FromStr, for example most error types. What determines whether a type should support FromStr? Examples to generalize:

• numbers
• IpAddr / SocketAddr
• Url
• LogLevel

Also the FromStr impl should match the Display impl. Are there any exceptions to this?

[Nemo157]

I would include any type that's likely to be passed via a command line flag/environment variable/non-structured config item. Having a generic way to parse values in all those places really makes getting the data you need into an application easy.

[Kixunil]

Are there any exceptions to this?

URL encoding? %41 should be decoded as A but it can be encoded as A.

[Nemo157]

So:

• If both a FromStr impl and Display impl are provided, FromStr should parse the output of Display and give back an equivalent object (x.to_string().parse() = Ok(x) ∀ x: FromStr + Display). This does not imply the inverse, FromStr will commonly be a lossy conversion, e.g. "0001".parse::<u32>() == Ok(1).

Although, there are still at least two stdlib types that might be an exception to this: f32 and f64. Looking at their documentation I can't find any info on whether they guarantee round-tripping through their default Display output.