When should I implement std::convert::From vs std::convert::Into?

by

TL;DR: prefer implementing From.

Interestingly, the original RFC about the std::convert traits suggested the opposite blanket implementation:

impl<T, U> From<T> for U
where
    T: Into<U>

But on the PR implementing it, it was changed to the opposite:

Added From => Into implementation, which makes it possible to add conversions in both directions without running afoul of coherence. For example, we now have From<[T]> for Vec<T> where T: Clone, which yields the corresponding Into going in the other direction — despite the fact that the two types live in different crates.

I also believe this addresses a few concerns about things implementing From instead of Into

This last-moment change reflects that From and Into are basically equivalent. From was chosen as the preferred one as it was less restrictive from the “type parameter vs. local type” point of view.

Before Rust 1.41.0, it wasn’t possible to make a impl<'a, T> Into<Foo> for &'a [T], while impl<'a, T> From<&'a [T]> for Foo was possible.

The first attempt raised a E0210:

error[E0210]: type parameter `T` must be used as the type parameter for some local type (e.g., `MyStruct<T>`)
 --> x.rs:3:10
  |
3 | impl<'a, T> Into<Foo> for &'a [T] {
  |          ^ type parameter `T` must be used as the type parameter for some local type
  |
  = note: only traits defined in the current crate can be implemented for a type parameter

In the standard library prior to Rust 1.14, there were only two examples of implementing Into and not From:

  • impl Into<Vec<u8>> for String
  • impl Into<OsString> for PathBuf

I think these are the reflexion of the logic of their interfaces. OsString implements From<String> and From<T> where T: AsRef<OsStr>, because they are the natural things you’ll want to build a OsString from.

However, PathBuf still implements Into<OsString> as the reverse operation of its From<OsString> implementation, but this logic belongs to PathBuf, not OsString.

More Related Contents:

  1. Traits and Rust
  2. Why do try!() and ? not compile when used in a function that doesn’t return Option or Result?
  3. Why do I need to import a trait to use the methods it defines for a type?
  4. Why does linking lifetimes matter only with mutable references?
  5. Why is adding a lifetime to a trait with the plus operator (Iterator + ‘a) needed?
  6. Should trait bounds be duplicated in struct and impl?
  7. Cannot infer an appropriate lifetime for autoref due to conflicting requirements
  8. How do I borrow a reference to what is inside an Option?
  9. What is lifetime elision in very simple terms?
  10. Why does this read input before printing?
  11. How to create a String directly?
  12. How to create an in-memory object that can be used as a Reader, Writer, or Seek in Rust?
  13. What’s the Rust idiom to define a field pointing to a C opaque pointer?
  14. Can’t borrow mutably within two different closures in the same scope
  15. What is the syntax to match on a reference to an enum?
  16. How can I implement Rust’s Copy trait?
  17. How to use a struct’s member as its own key when inserting the struct into a map without duplicating it?
  18. Why can’t I return an &str value generated from a String?
  19. How to implement a custom ‘fmt::Debug’ trait?
  20. How do I pass a closure through raw pointers as an argument to a C function?
  21. What is the prelude?
  22. How do I use a crate from another crate without explicitly defining a new dependency in my project?
  23. How do I specify that a struct field must implement a trait?
  24. How do I print an integer in binary with leading zeros?
  25. How to create and write to memory mapped files?
  26. How does Rust’s type inference work across multiple statements?
  27. Why does Valgrind not detect a memory leak in a Rust program using nightly 1.29.0?
  28. What is the null pointer optimization in Rust?
  29. Is there any way to restrict a generic type to one of several types?
  30. How to pass rustc flags to cargo?

Leave a Comment