Skip to content

Commit e978fa2

Browse files
leflonjsoverson
authored andcommitted
fix typo in chapter 6
1 parent 807a0d1 commit e978fa2

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

book/chapters/chapter-6-strings-part1.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -149,7 +149,7 @@ fn needs_a_string(argument: String) {}
149149

150150
`something.to_string()` converts _something_ into a string. It's commonly implemeted as part of the `Display` trait. You'll see a lot of posts that recommend `.to_string()` and a lot that don't.
151151

152-
The nuances in the recommendation stem from how much you want the compiler to help you. As your applications grow — especially when you start to deal with generics — you'll inevitably refactor some types into other types. A value that was initially a `&str` might end up being refactored into something else. If the new value still implements `Display`, then it has a `.to_string()` method. The compiler won't complain.t
152+
The nuances in the recommendation stem from how much you want the compiler to help you. As your applications grow — especially when you start to deal with generics — you'll inevitably refactor some types into other types. A value that was initially a `&str` might end up being refactored into something else. If the new value still implements `Display`, then it has a `.to_string()` method. The compiler won't complain.
153153

154154
In contrast, `.to_owned()` turns something borrowed into something owned, often by cloning. Turning a borrowed _`not-string`_ into an owned _`not-string`_ gives the compiler the context necessary to raise an error. If you're OK with the difference, it's easy to change a `.to_owned()` into a `.to_string()`. If you weren't expecting it, then you highlighted an issue before it became a problem.
155155

0 commit comments

Comments
 (0)