RFC: Deprecate FromStr in favor of TryFrom<&str>

[malobre]

Rendered

This is a work in progress.

[malobre]

I updated the RFC to be backward compatible (this is still a work in progress).

[BurntSushi]

I am strongly opposed to deprecating parse. It is widely used, and the churn that would be caused by deprecating that is unacceptable IMO.

I'd also rather we didn't deprecate FromStr either, since that is also pretty widely used.

I don't really see a lot of value in deprecating this stuff. This RFC is very light on details.

[shepmaster]

I am appreciative of the strangeness between FromStr and TryFrom. I wonder if a future hypothetical world with specialization would allow implementing one in terms of the other as a blanket implementation.

[malobre]

There has been some discussion about this here.

About the lack of details: I will add content. I just need some time to put my thoughts into writings.

[shepmaster]

I just need some time to put my thoughts into writings.

You may wish to re-read https://github.com/rust-lang/rfcs#before-creating-an-rfc

[clarfonthey]

I strongly feel that TryFrom should always be used instead of FromStr, and deprecating would be very useful. However, I'm very much not in favour of adding a blanket implementation, as it either requires specialisation or seriously limits possible impls.

A few things that influence my feelings:

1. The term parse gives a much different connotation than a simple string conversion. I can wrap a string in an error struct and I'd say that makes conversion reasonable, but I wouldn't call that parsing.
2. The blanket impl for From makes infallible conversions much more idiomatic.
3. The FromStr trait limits lifetimes in a way that prevents borrowing the passed string. For example, you can't convert &'a str into Wrapper<'a>; you must copy the string into a String if you do FromStr.

Honestly, I feel that the churn is very overstated. Deprecation exists for cases like this where a very clear alternative is there, and this is an example.

That said, I do agree that the RFC itself could do much better to elaborate on all of these points.

[clarfonthey]

To clarify: I think your enthusiasm in writing this RFC is wonderful, although I think that if you don't know a whole lot about the process it's much better to communicate with folks before submitting an RFC, and I know a lot of people would likely be willing to help you out.

The definition of breaking changes is probably one of the biggest things to know when it comes to writing an RFC and I'd say that you definitely want to read up on that first. I believe that there's actually an RFC for it, but as I'm on my phone I don't have the time to look up which one it is.

[malobre]

Thanks for your opinion, this RFC was clearly prematurely created. My apologies.

I've posted a topic for further discussion.

[ghost]

As a somewhat-new Rust user I experienced considerable confusion trying to figure out why both FromStr and TryFrom<&str> existed. I spent several hours banging my head against the wall trying to figure out why the standard library had a FromStr trait! I thought to myself: surely the Rust designers, having created such an amazing language, would not have included a superflous trait like this for no reason. There must be some secret super-power posessed by FromStr that I am not aware of. I must learn this secret super-power!

To my dismay, FromStr has no such secret super-powers. And I cannot recover the half-afternoon spent searching for them :(

I realize that deprecating FromStr and parse() will lead to lots of churn for experienced Rustaceans. But please realize that leaving them in the standard library for the rest of eternity will instead create much confusion for newcomers. Many, many more newcomers will waste half an afternoon like I did. Perhaps this is worse than current library maintainers each having to waste a day or two updating their code? Rust is still quite new and growing fast; there are certainly many more future users between now and the end of time than there are library maintainers in the year 2021.

In the meantime, please consider adding text to the docs explaining FromStr's historical provenance, its overlap with TryFrom<&str>, and the reason why FromStr still exists. This was the first place I went looking for an answer to "why does FromStr exist when we have TryFrom<&str>?".

I hope this comment is not perceived as unconstructive. Just wanted to provide some perspective from a new user.

[RustyYato]

Adding docs to FromStr about it's overlap with TryFrom<&str> sounds like a fantastic idea! I'm surprised there are no such docs already.

[malobre]

If anyone wishes to take over this RFC draft, be my guest.
I'm (unfortunately 😢) not using Rust for work and therefore can't currently spare much time contributing to the project.

[clarfonthey]

Honestly considering it. Not sure if I'll have a chance to give it a shot before the weekend.

[zbraniecki]

If I understand, for that to be possible, we'd need to cover all currently covered FromStr implementations in the stdlib with TryFrom<&str>. For example, at the moment usize implements FromStr but not TryFrom<&str>.

Getting that coverage could be done in parallel with this RFC, and would bring TryFrom<&str> up to par with FromStr.

Am I correct?

[malobre]

FYI, as noted here some crates implements FromStr and TryFrom<&str> for different purposes. Playground example.
But yes, this could be a separate RFC as this was more focused on deprecating FromStr.