Skip to content

Commit

Permalink
Explain that we do need to have 'static now
Browse files Browse the repository at this point in the history
  • Loading branch information
carols10cents committed Dec 11, 2020
1 parent 0b81c3b commit 4275162
Showing 1 changed file with 12 additions and 0 deletions.
12 changes: 12 additions & 0 deletions src/ch13-03-improving-our-io-project.md
Original file line number Diff line number Diff line change
Expand Up @@ -89,6 +89,16 @@ signature of the `Config::new` function so the parameter `args` has the type
`args` and we’ll be mutating `args` by iterating over it, we can add the `mut`
keyword into the specification of the `args` parameter to make it mutable.

We also needed to specify that the string slice error type can now only have
the `'static` lifetime. Because we’re only ever returning string literals, this
was true before. However, when we had a reference in the parameters, there was
the possibility that the reference in the return type could have had the same
lifetime as the reference in the parameters. The rules that we discussed in the
[“Lifetime Elision”][lifetime-elision] section of Chapter 10 applied, and we
weren’t required to annotate the lifetime of `&str`. With the change to `args`,
the lifetime elision rules no longer apply, and we must specify the `'static`
lifetime.

#### Using `Iterator` Trait Methods Instead of Indexing

Next, we’ll fix the body of `Config::new`. The standard library documentation
Expand Down Expand Up @@ -165,3 +175,5 @@ the iterator must pass.
But are the two implementations truly equivalent? The intuitive assumption
might be that the more low-level loop will be faster. Let’s talk about
performance.

[lifetime-elision]: ch10-03-lifetime-syntax.html#lifetime-elision

0 comments on commit 4275162

Please sign in to comment.