Description
- I have checked the latest
mainbranch to see if this has already been fixed - I have searched existing issues and pull requests for duplicates
URL to the section(s) of the book with this problem:
https://doc.rust-lang.org/book/ch12-03-improving-error-handling-and-modularity.html
Description of the problem:
fn new(args: &[String]) -> Result<Config, &str> { ... }
Due to lifetime elision rules, this ties the lifetime of the &str in the Result to the lifetime of args. It happens to compile with the main function given in listing 12-10, but this just seems like a lucky coincidence. An alternative main function would encounter an error due to the implied lifetime relationship:
fn main() {
let config = Config::new(&env::args().collect::<Vec<String>>());
let config = config.unwrap_or_else(|err| {
println!("Problem parsing arguments: {}", err);
process::exit(1);
});
}Suggested fix:
- Starting in listing 12-9, and in subsequent copies before listing 13-26, add a
'staticlifetime to the output str:fn new(args: &[String]) -> Result<Config, &'static str> { ... }
- Maybe add a brief explanation below listing 12-9 of why specifying
'staticmakes the signature better reflect what the function does. - After listing 13-26, remove the following paragraph:
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” 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.