4 ms·

Not a Rust expert by any means, this one piece of code from the example stuck out to me: `String::from("Ferris")`. What is the difference between that and `"Fer

Not a Rust expert by any means, this one piece of code from the example stuck out to me: `String::from("Ferris")`. What is the difference between that and `"Ferris"` on its own?

tyleraldrich 10y ago
String::from("Ferris") returns a String object (https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html) whereas "Ferris" on its own is a primative "str" (https://doc.rust-lang.org/std/primitive.str.html https://doc.rust-lang.org/std/primitive.str.html)
steveklabnik 10y ago
String literals have the type "&'static str", that is, an immutable reference to a string that lives for the entire program. As a reference, it doesn't have ownership over its contents. String is a growable, changable, string type. String::from will convert a &str to a String. It does have ownership over its contents. String is needed here because when you read something at runtime, you're not going to have a literal, of course. But when you're creating something from a literal, you'll have to convert it to a String. For a _much much_ more in-depth explanation that you don't need a _ton_ of Rust knowledge to understand, see http://rust-lang.github.io/book/ch04-00-understanding-ownership.html http://rust-lang.github.io/book/ch04-00-understanding-owners... (and its three sub-sections)
killercup 10y ago
The literal `"Ferris"` is a slice, i.e. a (const) pointer, which in this case will even point a part of to the data section of the binary. The String version is dynamically allocated and can be changed, can grow, etc.
IshKebab 10y ago
It's like `const char[]` vs `std::string`.
- moosingin3space 10y ago
  As someone who came from C++ to Rust, this analogy was most helpful for me. I can understand why it seems a little odd to someone without a systems background, though.
cesarb 10y ago
With "Ferris", these six bytes are in your program's read-only data section; the "Ferris" expression actually returns a reference to these six bytes (this reference is a "fat" pointer, which consists of a word with the address of the first byte and another word with their length, in this case 6). The String::from("Ferris") method call returns a String. With the String, these six bytes are in the heap; internally, a String is similar to a Vec<u8> (heap-allocated vector of bytes).
msbarnett 10y ago
It's like in C. "Ferris" is a pointer (and length, in Rust) into the binary's static storage segment. String::from("Ferris") creates a pointer to a string on the heap with the contents "Ferris". The difference is that in C this distinction is implicit, so you can accidentally try to modify the string in static storage, which is undefined behaviour, whereas Rust treats these distinct things as distinct types.
- panic 10y ago
  This makes C's approach sound worse than it really is: in practice you'll either get a compiler warning or a segfault, not the potential nose-demons typically associated with undefined behavior. C also gives you a type-level way to track static strings (the const qualifier) though it isn't as strictly enforced.

Not a Rust expert by any means, this one piece of code from the example stuck out to me: `String::from("Ferris")`. What is the difference between that and `"Ferris"` on its own?

tyleraldrich 10y ago

String::from("Ferris") returns a String object (https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html) whereas "Ferris" on its own is a primative "str" (https://doc.rust-lang.org/std/primitive.str.html https://doc.rust-lang.org/std/primitive.str.html)

steveklabnik 10y ago

String literals have the type "&'static str", that is, an immutable reference to a string that lives for the entire program. As a reference, it doesn't have ownership over its contents. String is a growable, changable, string type. String::from will convert a &str to a String. It does have ownership over its contents. String is needed here because when you read something at runtime, you're not going to have a literal, of course. But when you're creating something from a literal, you'll have to convert it to a String. For a _much much_ more in-depth explanation that you don't need a _ton_ of Rust knowledge to understand, see http://rust-lang.github.io/book/ch04-00-understanding-ownership.html http://rust-lang.github.io/book/ch04-00-understanding-owners... (and its three sub-sections)

killercup 10y ago

The literal `"Ferris"` is a slice, i.e. a (const) pointer, which in this case will even point a part of to the data section of the binary. The String version is dynamically allocated and can be changed, can grow, etc.

IshKebab 10y ago

It's like `const char[]` vs `std::string`.

moosingin3space 10y ago
As someone who came from C++ to Rust, this analogy was most helpful for me. I can understand why it seems a little odd to someone without a systems background, though.

cesarb 10y ago

With "Ferris", these six bytes are in your program's read-only data section; the "Ferris" expression actually returns a reference to these six bytes (this reference is a "fat" pointer, which consists of a word with the address of the first byte and another word with their length, in this case 6). The String::from("Ferris") method call returns a String. With the String, these six bytes are in the heap; internally, a String is similar to a Vec<u8> (heap-allocated vector of bytes).

msbarnett 10y ago

It's like in C. "Ferris" is a pointer (and length, in Rust) into the binary's static storage segment. String::from("Ferris") creates a pointer to a string on the heap with the contents "Ferris". The difference is that in C this distinction is implicit, so you can accidentally try to modify the string in static storage, which is undefined behaviour, whereas Rust treats these distinct things as distinct types.

panic 10y ago
This makes C's approach sound worse than it really is: in practice you'll either get a compiler warning or a segfault, not the potential nose-demons typically associated with undefined behavior. C also gives you a type-level way to track static strings (the const qualifier) though it isn't as strictly enforced.