Recently the implementation of From<T> for Option<T> was merged.
Should From<T> be implemented for other types, like Cell<T>, RefCell<T>, Box<T>, Rc<T> and Arc<T>?
Those all seem like reasonable implementations, and some of them already exist like Box, Arc, and Rc.
Is there some trade-off between implementing Deref or From? Is it possible to have both?
Its completely possible; there’s not really any relationship. Box for example already implements both.
I made a pull request with From implementation for Cell, RefCell and UnsafeCell.
I was recently thinking that having From<T> impls for both String and &str (as well perhaps as Path and PathBuf, and maybe even OsStr/OsString) would be useful in improving ergonomics.
It happens way too often that I e.g. need a String but only have a &str and so need to call my_str.to_string() explicitly.
While not a major thing, it is annoying to have to do again and again.
Next to the above, atm String only implements FromStr which sort of seems to have the same purpose as From, except having From for it would be strictly better as the API would be identical to any other From, rather than having some weird special case conversion trait.
BTW:
I realize that Rust has a philosophy of making all allocations explicit, but that guarantee went out the window as soon as From impls started appearing in 3rd party libs.
I also realize FromStr won’t be removed as it’s marked as stable, but deprecation in favor of a From impl for String doesn’t seem like a weird move to me. Of course, there may be factors at play I’m not familiar with 
1 Like
Don’t those already exist? https://is.gd/KQxpQq
Huh. You’re absolutely right. I both literally and figuratively did not see that coming… Just disregard my previous post then.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.