Trait core::convert::From 1.0.0[−][src]
Expand description
Used to do value-to-value conversions while consuming the input value. It is the reciprocal of
Into
.
One should always prefer implementing From
over Into
because implementing From
automatically provides one with an implementation of Into
thanks to the blanket implementation in the standard library.
Only implement Into
when targeting a version prior to Rust 1.41 and converting to a type
outside the current crate.
From
was not able to do these types of conversions in earlier versions because of Rust’s
orphaning rules.
See Into
for more details.
Prefer using Into
over using From
when specifying trait bounds on a generic function.
This way, types that directly implement Into
can be used as arguments as well.
The From
is also very useful when performing error handling. When constructing a function
that is capable of failing, the return type will generally be of the form Result<T, E>
.
The From
trait simplifies error handling by allowing a function to return a single error type
that encapsulate multiple error types. See the “Examples” section and the book for more
details.
Note: This trait must not fail. If the conversion can fail, use TryFrom
.
Generic Implementations
From<T> for U
impliesInto
<U> for T
From
is reflexive, which means thatFrom<T> for T
is implemented
Examples
String
implements From<&str>
:
An explicit conversion from a &str
to a String is done as follows:
let string = "hello".to_string();
let other_string = String::from("hello");
assert_eq!(string, other_string);
RunWhile performing error handling it is often useful to implement From
for your own error type.
By converting underlying error types to our own custom error type that encapsulates the
underlying error type, we can return a single error type without losing information on the
underlying cause. The ‘?’ operator automatically converts the underlying error type to our
custom error type by calling Into<CliError>::into
which is automatically provided when
implementing From
. The compiler then infers which implementation of Into
should be used.
use std::fs;
use std::io;
use std::num;
enum CliError {
IoError(io::Error),
ParseError(num::ParseIntError),
}
impl From<io::Error> for CliError {
fn from(error: io::Error) -> Self {
CliError::IoError(error)
}
}
impl From<num::ParseIntError> for CliError {
fn from(error: num::ParseIntError) -> Self {
CliError::ParseError(error)
}
}
fn open_and_parse_file(file_name: &str) -> Result<i32, CliError> {
let mut contents = fs::read_to_string(&file_name)?;
let num: i32 = contents.trim().parse()?;
Ok(num)
}
RunRequired methods
Implementors
Maps a byte in 0x00..=0xFF to a char
whose code point has the same value, in U+0000..=U+00FF.
Unicode is designed such that this effectively decodes bytes with the character encoding that IANA calls ISO-8859-1. This encoding is compatible with ASCII.
Note that this is different from ISO/IEC 8859-1 a.k.a. ISO 8859-1 (with one less hyphen), which leaves some “blanks”, byte values that are not assigned to any character. ISO-8859-1 (the IANA one) assigns them to the C0 and C1 control codes.
Note that this is also different from Windows-1252 a.k.a. code page 1252, which is a superset ISO/IEC 8859-1 that assigns some (not all!) blanks to punctuation and various Latin characters.
To confuse things further, on the Web
ascii
, iso-8859-1
, and windows-1252
are all aliases
for a superset of Windows-1252 that fills the remaining blanks with corresponding
C0 and C1 control codes.
Stability note: This impl does not yet exist, but we are “reserving space” to add it in the future. See rust-lang/rust#64715 for details.