There are many ways to convert these types between each other; these are the most straightforward, least surprising ones I've found. Please see the happy path test cases for what I expect their behavior to be.
Some of these conversions, the ones that use .unwrap(), may panic if the conversion can't be performed on the input you supply!
| Want x to be ▶ Have an x of type ▼ |
i32 | u32 | String | f64 |
|---|---|---|---|---|
| i32 | n/a | x as u32 | x.to_string() | x as f64 |
| u32 | x as i32 | n/a | x.to_string() | x as f64 |
| String* | x.parse().unwrap() | x.parse().unwrap() | n/a | x.parse().unwrap() |
| f64 | x as i32 | x as u32 | x.to_string() | n/a |
* Observant readers will notice that yes, the code for converting Strings to i32, u32, AND f64 is all the same — how can that be??? Type inference! If Rust can't infer the type that you're trying to get from the context in which you're using it, you can give it a hint by doing, for example, x.parse::<i32>().unwrap(), but that usually isn't necessary.
If you have a variable x, and you get the message "expected `type`, found `core::option::Option<type>`", you can use the following code with the following consequences. There is more detail and more ways to handle Options in the Error Handling section of the Rust Programming Language book.
| Code | Consequence when you get None |
|---|---|
x.unwrap_or(put_default_value_here) |
You will get the value you put where it says put_default_value_here. |
x.expect("My Custom Error Message") |
Panic with a custom error message |
x.unwrap() |
Panic (not recommended in production code, handle your error cases!) |
Strings are... special. It's a long story that the Strings section of the Rust Programming Language book goes into.
I've pulled the string types out into a separate table because it's not possible to get an &str without going through String, so it would add a lot of redundancy. Also, when converting between string slices (&str) and in-memory strings (String), you will need to consider the lifetime you intend these to have.
Also note that collections::string is re-exported as std::string, so if you get an error message saying "expected collections::string::String", that's the same as if the error message said "expected String".
So. Here are the ways to convert between these when the lifetimes can be inferred:
| Want x to be ▶ Have an x of type ▼ |
String | &str |
|---|---|---|
| String | n/a | &*x |
| &str | x.to_string() | n/a |
| Want x to be ▶ Have an x of type ▼ |
Vec<T> | &[T] | Box<[T]> |
|---|---|---|---|
| Vec<T> | n/a | &x[..] | x.into_boxed_slice() |
| &[T] | x.to_vec() | n/a | Box::new(*x) |
| Box<[T]> | x.into_vec() | &*x | n/a |
Bare [T], referring to some number of T in contiguous memory, are rarely useful. Usually, you want a "borrowed slice", &[T], which consists of a pointer to that memory and a count of the number of T present. If you somehow have a [T] and need &[T] instead, simply use &x.
I hope you find this helpful! <3
I'm just a person who makes mistakes just like you, and Rust changes frequently, so if something on this page isn't right, please make a correction!
This is not an official Rust project.