{
Ok(Dummy(s))
}
}
// This works
impl<'a> From<&'a str> for Dummy<'a> {
fn from(s: &'a str) -> Self {
Dummy(s)
}
}
```
In the premature RFC I posted some concerns were raised about the churn created by this deprecation as [`FromStr`](https://doc.rust-lang.org/std/str/trait.FromStr.html) is widely used.
---
### Author:  [@burntsushi](https://internals.rust-lang.org/u/burntsushi)
#### Post date: [May 12, 2020, 1:51pm UTC](https://internals.rust-lang.org/t/pre-rfc-deprecate-fromstr-in-favor-of-tryfrom-str/12331/2 "2020-05-12T13:51:39Z")
As I said on the PR, I am _strongly_ opposed to deprecating `parse`. It is ubiquitous in Rust code, and the churn it would cause is mind boggling, especially since it still works just fine. Its main problem is that it is a bit redundant. I personally don't feel like that rises to level of deprecating it.
Deprecating `FromStr` wouldn't be as bad as deprecating `parse` (if that's even possible), but it is still widely used, and as with `parse`, works just fine.
Overall, I'd like to see fewer deprecations in general, or at the very least, group them together so that they can all be addressed at once instead of spreading them out. But this particular deprecation doesn't seem well motivated IMO.
---
### Author:  [@djc](https://internals.rust-lang.org/u/djc)
#### Post date: [May 12, 2020, 2:00pm UTC](https://internals.rust-lang.org/t/pre-rfc-deprecate-fromstr-in-favor-of-tryfrom-str/12331/3 "2020-05-12T14:00:44Z")
Perhaps we could start with a blanket `impl FromStr for T where T: TryFrom<&str>`? We could keep `parse()` while at the same time guiding developers towards the more general `TryFrom` trait.
Personally I'm not as a big a fan of `parse()` since I feel it is pretty hard to understand how that works if you're encountering as a new user. By comparison, I feel like `try_into()` generalizes better and makes it slightly clearer what's going on under the covers.
---
### Author:  [@RustyYato](https://internals.rust-lang.org/u/RustyYato)
#### Post date: [May 12, 2020, 2:12pm UTC](https://internals.rust-lang.org/t/pre-rfc-deprecate-fromstr-in-favor-of-tryfrom-str/12331/4 "2020-05-12T14:12:13Z")
I'm pretty sure that's potentially unsound because of lifetime specializations (any specialization only using a trait bound is potentially unsound). This means we can't expose it in a public api, because specialization is likely to change in significant ways to fix this soundness hole. (Also, we don't expose unstable features, like specialization in public apis, i.e. it should be possible to remove all uses of specialization without breaking anyone's builds).
---
### Author:  [@bascule](https://internals.rust-lang.org/u/bascule)
#### Post date: [May 13, 2020, 4:06am UTC](https://internals.rust-lang.org/t/pre-rfc-deprecate-fromstr-in-favor-of-tryfrom-str/12331/5 "2020-05-13T04:06:21Z")
One thing I love about `parse()` is it's an inherent method and therefore you don't need any traits in scope to use it.
At present `TryInto` is not in the prelude, so using it for parsing means you have to import it every time.
> [@djc](#):
>
> Perhaps we could start with a blanket `impl FromStr for T where T: TryFrom<&str>` ? We could keep `parse()`
This makes the most sense to me. I'd suggest not deprecating `parse` _at least_ until when/if `TryInto` winds up in a future (edition) prelude and can then be used as easily as `parse()` can today.
---
### Author:  [@kennytm](https://internals.rust-lang.org/u/kennytm)
#### Post date: [May 13, 2020, 6:22pm UTC](https://internals.rust-lang.org/t/pre-rfc-deprecate-fromstr-in-favor-of-tryfrom-str/12331/6 "2020-05-13T18:22:23Z")
In the current libstd, `.try_into()` and `.parse()` are different for how they should work.
`.try_into()`, as a fallible version of `.into()`, mostly transforms the "shape" of the value to fit another type.
`.parse()` can be considered the reverse of `.to_string()`, will read the string content to reconstruct a value in the target type.
Additionally, `TryFrom` must satisfy this relationship, which is not bound for `FromStr`:
- `T: From` ⇒ `T: TryFrom`
* * *
As a concrete example:
```rust
use std::convert::TryInto;
use serde_json::{Value, json};
fn main() {
let a: Value = "[1, 2, 3]".try_into().unwrap();
let b: Value = "[1, 2, 3]".parse().unwrap();
assert_eq!(dbg!(a), json!("[1, 2, 3]"));
assert_eq!(dbg!(b), json!( [1, 2, 3] ));
}
```
---
### Author:  [@yaahc](https://internals.rust-lang.org/u/yaahc)
#### Post date: [May 14, 2020, 3:42pm UTC](https://internals.rust-lang.org/t/pre-rfc-deprecate-fromstr-in-favor-of-tryfrom-str/12331/7 "2020-05-14T15:42:14Z")
One problem that I haven't seen mentioned is that TryFrom doesn't get to use deref coercion the same way FromStr can due to the lack of an explicit receiving type. Using TryFrom exclusively would require a lot of additions of as\_ref() or &\* to code that otherwise just works via FromStr.
---
### Author:  [@system](https://internals.rust-lang.org/u/system)
#### Post date: [August 12, 2020, 3:43pm UTC](https://internals.rust-lang.org/t/pre-rfc-deprecate-fromstr-in-favor-of-tryfrom-str/12331/8 "2020-08-12T15:43:48Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.