DEV Community: SomeB1oody

[Rust Guide] 11.1. Writing and Running Tests

SomeB1oody — Mon, 04 May 2026 02:39:40 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

11.1.1 What Is Testing

In Rust, a test is a function used to verify whether non-test code behaves as expected.

A test function usually performs three actions:

Arrange data/state
Act on the code under test
Assert the result

In some languages, these three actions are called the 3A steps.

11.1.2 Anatomy of a Test Function

A test function is still just a function; the difference is that it must be annotated with the test attribute.

An attribute is metadata for Rust code. It does not change the logic of the code it decorates; it only adds decoration, or annotation. In fact, we already used this in 5.2. Struct Usage Example - Printing Debug Information.

Adding #[test] to a function turns it into a test function.

11.1.3 Running Tests

Putting aside what is inside the test function for now, how do we run it after writing it? We use the cargo test command to run all tests.

This command builds a test runner executable. It runs the functions annotated with test one by one and reports whether they succeeded.

When you create a library project with Cargo, it generates a test module with a ready-made test function that you can use as a reference when writing other test functions. In fact, you can add any number of test modules or test functions.

For example:
Create a new library project named adder:

$ cargo new adder --lib
     Created library `adder` project
$ cd adder

Open the project (lib.rs):

pub fn add(left: usize, right: usize) -> usize { 
left + right 
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_works() {
        let result = add(2, 2);
        assert_eq!(result, 4);
    }
}

This is a test function because it is annotated with #[test], not because it is inside a test module. A test module can also contain ordinary functions.

Use cargo test to run the tests:

$ cargo test
   Compiling adder v0.1.0 (file:///projects/adder)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.57s
     Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4)

running 1 test
test tests::it_works ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests adder

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Let’s analyze this output:

First come compiling, finishing, and running.
Next is running 1 test, which means one test is being executed. The next line shows that the test is tests::it_works. Its result is ok. This project has only one test, but if there were multiple tests, cargo test would run all of them.
Then comes test result: ok., which means all tests in the project passed. Specifically, 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out means one test passed, zero failed, zero were ignored, zero were benchmark tests, and zero were filtered out.
Doc-tests adder refers to the results of documentation tests. Rust can compile code that appears in API documentation, which helps ensure that documentation always stays in sync with the actual code.

If we rename the function, where will the output change?

pub fn add(left: usize, right: usize) -> usize {
    left + right
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn exploration() { // renamed to exploration
        let result = add(2, 2);
        assert_eq!(result, 4);
    }
}

Output:

$ cargo test
   Compiling adder v0.1.0 (file:///projects/adder)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.59s
     Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4)

running 1 test
test tests::exploration ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests adder

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

You can see that the test name changed from tests::it_works to tests::exploration.

11.1.4 Test Failures

If a test function triggers panic!, the test fails. Since each test runs in its own thread, the main thread monitors those threads. When the main thread sees that a test has crashed by triggering panic!, that test is marked as failed.

For example:

pub fn add(left: usize, right: usize) -> usize {
    left + right
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn exploration() {
        let result = add(2, 2);
        assert_eq!(result, 4);
    }

    #[test]
    fn another() {
        panic!("Make this test fail");
    }
}

The another function calls panic! directly. Run it and see the result:

$ cargo test
   Compiling adder v0.1.0 (file:///projects/adder)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.72s
     Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4)

running 2 tests
test tests::another ... FAILED
test tests::exploration ... ok

failures:

---- tests::another stdout ----
thread 'tests::another' panicked at src/lib.rs:17:9:
Make this test fail
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    tests::another

test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--lib`

tests::another failed, while tests::exploration is still ok. The reason is thread 'tests::another' panicked at src/lib.rs:17:9, which means panic! was triggered at line 17, column 9 of src/lib.rs, that is, where the macro appears in the source code.

To summarize, test result: FAILED means the overall test run failed. More specifically, 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out.

[RustGuide] 10.8. Lifetime Annotations in Method Definitions and Static Lifetime

SomeB1oody — Fri, 01 May 2026 23:46:02 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

10.8.1 Lifetime Annotations in Method Definitions

Do you still remember the three lifetime elision rules mentioned in the previous article, 10.7. Input and Output Lifetimes and the 3 Rules?

Rule 1: Each reference parameter gets its own lifetime. A single-parameter function has one lifetime, a two-parameter function has two lifetimes, and so on.

Rule 2: If there is exactly one input lifetime parameter, that lifetime is assigned to all output lifetime parameters. In other words, if there is only one input lifetime, that lifetime is the lifetime of every possible return value of the function.

Rule 3: If there are multiple input lifetime parameters, but one of them is &self or &mut self (that is, the function is a method), then the lifetime of self is assigned to all output lifetime parameters.

In the example from the previous article, we applied Rules 1 and 2, but not Rule 3, because Rule 3 applies only to methods. So here we will talk about Rule 3, which is lifetime annotations in method definitions.

A method needs a struct, and using lifetimes on a struct when defining methods works the same way as generic parameters do (see 10.7. Input and Output Lifetimes and the 3 Rules).

Where a lifetime parameter is declared and used depends on whether the lifetime parameter is related to fields, method parameters, or return values.

Lifetime names for struct fields are always declared after the impl keyword and then used after the struct name, because these lifetimes are part of the struct type itself.

Inside method signatures in an impl block, references must be tied to the lifetime of the struct field reference, or they can also be independent. In addition, lifetime elision rules often make lifetime annotations unnecessary in methods.

Enough talk—let’s look at an example:

struct ImportantExcerpt<'a> {
    part: &'a str,
}

impl<'a> ImportantExcerpt<'a> {
    fn level(&self) -> i32 {
        3
    }
}

fn main() {
    let novel = String::from("Call me Ishmael. Some years ago...");
    let first_sentence = novel.split('.').next().unwrap();
    let i = ImportantExcerpt {
        part: first_sentence,
    };
}

First, the ImportantExcerpt struct is defined, and then the level method is defined for it. The level method takes only &self as a parameter, and its return value is i32, so it does not reference anything.

The phrase “lifetime names for struct fields are always declared after the impl keyword and then used after the struct name” refers to the fact that line 4 writes <'a> after impl, and <'a> is also written after the struct name ImportantExcerpt.

Note that neither of the two <'a> annotations on line 4 can be omitted, but the level function does not need a lifetime annotation on &self because lifetime elision Rules 1 and 2 apply.

Now add another method:

impl<'a> ImportantExcerpt<'a> {
    fn announce_and_return_part(&self, announcement: &str) -> &str {
        println!("Attention please: {announcement}");
        self.part
    }
}

According to lifetime elision Rule 1, the &self and announcement parameters each receive a lifetime:

impl<'a> ImportantExcerpt<'a> {
    fn announce_and_return_part<'a, 'b>(&'a self, announcement: &'b str) -> &str {
        println!("Attention please: {announcement}");
        self.part
    }
}

According to lifetime elision Rule 3, the return value is assigned the same lifetime as &self:

impl<'a> ImportantExcerpt<'a> {
    fn announce_and_return_part<'a, 'b>(&'a self, announcement: &'b str) -> &'a str {
        println!("Attention please: {announcement}");
        self.part
    }
}

At this point, all lifetimes have been inferred, so the compiler can compile the code successfully.

10.8.2 The `'static` Lifetime

Rust has a special lifetime called 'static, which means the entire duration of the program, or the whole execution time of the program.

For example, all string literals have the 'static lifetime, such as:

let s: &'static str = "I have a static lifetime.";

This is a string literal, so it can be annotated with 'static.

The reason string literals have the 'static lifetime is that they are stored directly in the binary file and placed in static memory at runtime, so they are always available.

Before assigning 'static to an ordinary reference—which the compiler often suggests when it reports an error—you must think carefully: do you really need this reference to live for the entire duration of the program? Most likely, the compiler error appears because of a dangling reference or a lifetime mismatch. At that point, you should try to solve those problems instead of simply slapping a 'static lifetime on it.

10.8.3 Generic Type Parameters, Trait Bounds, and Lifetimes

Finally, let’s look at an example that uses generic type parameters, trait bounds, and lifetimes at the same time:

use std::fmt::Display;

fn longest_with_an_announcement<'a, T>(
    x: &'a str,
    y: &'a str,
    ann: T,
) -> &'a str
where
    T: Display,
{
    println!("Announcement! {ann}");
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

The purpose of this function is to return the longer of the two string slices x and y, but it now has one more parameter, ann, which stands for announcement. Its type is the generic type T, and according to the constraint in where, T can be replaced by any type that implements the Display trait.

[Rust Guide] 10.7. Input and Output Lifetimes and the 3 Rules

SomeB1oody — Fri, 01 May 2026 23:41:06 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

10.7.1 A Deeper Understanding of Lifetimes

1. The Way Lifetime Parameters Are Specified Depends on What the Function Does

Take the code from the previous article as an example:

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {  
    if x.len() > y.len() {  
        x  
    } else {  
        y  
    }  
}

The reason this function signature is written this way is that it is not known whether the return value will be x or y. If I modify the code so that the return value is fixed as x, then there is no need to give y an explicit lifetime:

fn longest<'a>(x: &'a str, y: &str) -> &'a str {  
    x
}

So this function signature does not constrain y’s lifetime.

2. When a Function Returns a Reference, the Lifetime Parameter of the Return Type Must Match One of the Input Lifetimes

If the returned reference does not point to any parameter, the returned content becomes a dangling reference, because a value created inside the function leaves scope when the function ends, and the returned reference points to memory that has been freed.

Take this example:

fn longest<'a>(x: &'a str, y: &str) -> &'a str {  
    let result = String::from("Something");
    result.as_str()
}

In this function, a String value named result is created, and then the as_str method is called on result to return a string slice (&str), which is really just a reference. That then causes an error:

error[E0515]: cannot return value referencing local variable `result`
  --> src/main.rs:13:5
   |
13 |     result.as_str()
   |     ------^^^^^^^^^
   |     |
   |     returns a value referencing data owned by the current function
   |     `result` is borrowed here

The error message says that a value referencing the local variable result cannot be returned, because the returned value is data owned by the function itself. This is the same reason mentioned just now: once the internal data goes out of scope, it is cleaned up.

What if I want to return a value created inside the function? Then I do not return a reference; I return the value directly:

fn longest(x: &str, y: &str) -> String {  
    let result = String::from("Something");
    result
}

This is equivalent to transferring ownership of the function’s value to the caller, and the caller is responsible for cleaning up that memory. This version also does not need an explicit lifetime, because the return value has nothing to do with the parameters, and only references have lifetime problems.

From this example, you can see that lifetime syntax is fundamentally used to relate the lifetimes of a function’s different parameters and return values. Once those relationships are established, Rust has enough information to support operations that preserve memory safety and to reject operations that could lead to dangling pointers or other violations of memory safety.

10.7.2 Lifetime Annotations in Structs

In earlier articles, we only defined self-owned types in structs, such as i32 and String. In fact, struct fields can also be reference types, and if they are references, you need to add lifetime annotations to each reference.

Take this example:

struct ImportantExcerpt<'a> {
    part: &'a str,
}

fn main() {
    let novel = String::from("Call me Ishmael. Some years ago...");
    let first_sentence = novel.split('.').next().unwrap();
    let i = ImportantExcerpt {
        part: first_sentence,
    };
}

ImportantExcerpt has only one field, part, and its type is a string slice, which is a reference type. Because it is a reference type, a lifetime annotation is required.

The way to annotate a lifetime is the same as with generics: add <> after the struct name and write the lifetime generic parameter inside it. Here that is 'a. The part reference must live longer than the struct instance itself. As long as the instance exists, the part reference must also exist; if part disappears first, the instance will definitely be invalid.

Look at main: it first creates a String named novel, then uses split and next to extract the first sentence from the string (unwrap is used to unwrap the Option type, which was introduced in 9.2. Result Enum and Recoverable Errors Pt.1). The type of this sentence is &str, which is a reference. Then it creates an instance i of ImportantExcerpt and uses that reference as the value of the part field.

This is valid because the scope of first_sentence is from line 7 to line 11, while the scope of i is from line 8 to line 11. So the part field lives longer than the instance and fully covers i’s lifetime.

10.7.3 Lifetime Elision

Every reference has a lifetime, and functions or structs that use lifetimes need lifetime parameters.

Then why does this code, taken from 4.5. Slice, compile without any lifetime annotations?

fn main() {
    let s = String::from("Hello world");
    let word = first_word(&s);
    println!("{}", word);
}
fn first_word(s:&str) -> &str {
    let bytes = s.as_bytes();
    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[..i];
        } 
    }
    &s[..]
}

The reason this function compiles without lifetime annotations has historical roots: in early versions of Rust (before 1.0), this code would not compile, because every reference was required to have an explicit lifetime. The function signature would have had to look like this:

fn first_word<'a>(s: &'a str) -> &'a str {

Later, the Rust team found that in certain situations Rust programmers kept writing the same lifetime annotations over and over, and those situations were predictable. They had clear patterns, so the Rust team encoded those patterns directly into the compiler, allowing the borrow checker to infer lifetimes automatically in those cases without explicit annotations from the programmer.

The significance of knowing this history is that more deterministic patterns may be discovered in the future and added to the compiler. In the future, there may be fewer lifetime annotations to write. Thank goodness.

The patterns built into Rust’s reference analysis are called the lifetime elision rules. Programmers do not need to follow them manually; they are special cases handled by the compiler. If your code matches these cases, explicit lifetime annotations are unnecessary.

However, lifetime elision does not provide complete inference. If a reference is still ambiguous after the rule is applied, a compilation error will still occur. The solution is to add lifetimes manually to show the relationships between references.

10.7.4 Input and Output Lifetimes

If a lifetime appears in a function or method parameter, it is called an input lifetime.

If it appears in a function or method return value, it is called an output lifetime.

10.7.5 The Three Rules of Lifetime Elision

The compiler uses three rules to determine lifetimes when they are not explicitly annotated:

Rule 1 is used for input lifetimes
Rules 2 and 3 are used for output lifetimes
If the compiler still cannot determine the lifetime after applying all three rules, it reports an error
These three rules apply not only to function or method definitions, but also to impl blocks

Rule 1: Each reference parameter gets its own lifetime. A single-parameter function has one lifetime, a two-parameter function has two lifetimes, and so on.

1. Successful Example

Now that the rules are clear, let’s look at an example:

fn first_word(s:&str) -> &str {
    //...
}

Put yourself in the compiler’s place and think about how to use the three rules to find the omitted lifetime in this function signature.

First, apply Rule 1—each reference parameter gets its own lifetime. There is only one parameter here, so there is only one lifetime. At this point, the compiler infers:

fn first_word<'a>(s:&'a str) -> &str {
    //...
}

Because there is only one input lifetime, Rule 2 also applies here—if there is exactly one input lifetime parameter, that lifetime is assigned to all output lifetime parameters. So the input lifetime is assigned to the output lifetime. At this point, the compiler infers:

fn first_word<'a>(s:&'a str) -> &'a str {
    //...
}

Because there is only one input lifetime, and this function is not a method, Rule 3 does not apply.

Now every reference in the function has a lifetime, so the compiler can continue analyzing the code without the programmer manually annotating the lifetimes in the function signature.

2. Failure Example

Look at the second example:

fn longest(x:&str, y:&str) -> &str {
    //...
}

This function signature has two reference inputs, and the return type is also a reference. Try these three rules:

First, apply Rule 1—each reference parameter gets its own lifetime. There are two parameters here, so there are two lifetimes:

fn longest<'a, 'b>(x:&'a str, y:&'b str) -> &str {
    //...
}

Because there are two reference parameters, Rule 2 does not apply.

Because this function is not a method, Rule 3 does not apply.

After applying all three rules, the return value’s lifetime is still undetermined, so the compiler reports an error. In other words, you must declare the lifetime explicitly.

[Rust Guide] 10.6. Lifetime Syntax and Examples

SomeB1oody — Thu, 30 Apr 2026 18:09:34 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

10.6.1 Lifetime Annotation Syntax

Annotating lifetimes does not change how long a reference lives.
If a function specifies generic lifetime parameters, it can accept references with any lifetime.
Lifetime annotations are mainly used to describe relationships between the lifetimes of multiple references, but they do not affect lifetimes themselves.

Lifetime parameter names must start with ', are usually all lowercase, and are very short. Many developers use 'a as the lifetime parameter name.

Lifetime annotations go after the & symbol, and a space separates the annotation from the reference type.

10.6.2 Lifetime Annotation Examples

&i32: a plain reference
&'a i32: a reference with an explicit lifetime, where the referenced type is i32
&'a mut i32: a mutable reference with an explicit lifetime

A single lifetime annotation by itself is meaningless. The purpose of lifetime annotations is to describe the relationships between multiple generic lifetimes to Rust.

Take the code from the previous article as an example:

fn main() {  
    let string1 = String::from("abcd");  
    let string2 = "xyz";  

    let result = longest(string1.as_str(), string2);  
    println!("The longest string is {result}");  
}  

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {  
    if x.len() > y.len() {  
        x  
    } else {  
        y  
    }  
}

The lifetimes of the parameter x, the parameter y, and the return value in longest are all 'a, which means that x, y, and the return value must have the “same” lifetime.

From the example above, you can also see that when using lifetime annotations in a function signature, generic lifetime parameters must be declared inside <>. This signature tells Rust that there is a lifetime 'a, and that x, y, and the return value must live at least as long as 'a.

Because lifetime annotations are mainly used to describe relationships between the lifetimes of multiple references, but they do not affect lifetimes themselves, this writing does not change the lifetimes of the arguments. It only gives the borrow checker constraints that can be used to detect invalid calls. So the longest function does not need to know exactly how long x and y live; it only needs some scope that can stand in for 'a while satisfying the function signature’s constraints.

When a function references code outside itself, or when it is referenced by outside code, it is almost impossible to determine the lifetimes of the parameters and return values using Rust compiler alone. The lifetimes used by such a function may change from call to call. That is exactly why lifetimes sometimes need to be annotated manually.

In the example code, when we pass concrete references into the longest function, which scope is used to replace 'a? It is the overlapping part of the scopes of x and y, in other words, the shorter of the two lifetimes. And because the return value also has lifetime 'a, the returned reference remains valid in the overlap between the scopes of x and y.

That is why in the previous article and earlier in this article, the word “same” was placed in quotes: it does not mean literally identical lifetimes, but rather the overlapping part.

Next, let’s see how lifetime annotations constrain calls to longest. If we change the example above so that string1 has a different scope and string2 becomes a String, what happens?

fn main() {  
    let string1 = String::from("abcd");  
    {  
        let string2 = String::from("xyz");  
        let result = longest(string1.as_str(), string2.as_str());  
        println!("The longest string is {result}");  
    }  
}  

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {  
    if x.len() > y.len() {  
        x  
    } else {  
        y  
    }  
}

Here, the scope of string1 is from line 2 to line 8, and the scope of string2 is from line 4 to line 7. When these are passed into longest, the function looks for the overlapping part—or, in other words, the shorter lifetime—which is the scope of string2, from line 4 to line 7. So the scope represented by 'a is from line 4 to line 7. result is valid inside the inner scope, that is, until the closing brace on line 7, so the code is still valid within 'a.

What if I change the scope of result instead?

fn main() {  
    let string1 = String::from("abcd");  
    let result;  
    {  
        let string2 = String::from("xyz");  
        result = longest(string1.as_str(), string2.as_str());  
    }  
    println!("The longest string is {result}");  
}  

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {  
    if x.len() > y.len() {  
        x  
    } else {  
        y  
    }  
}

In this case, the scope of string1 is from line 2 to line 9, and the scope of string2 is from line 5 to line 7. When these are passed into longest, the function looks for the overlapping part—or, in other words, the shorter lifetime—which is the scope of string2, from line 5 to line 7. So the generic lifetime parameter 'a of the function refers to the scope from line 5 to line 7, and the return value should also have that same scope. However, the result variable that receives the return value actually lives from line 3 to line 9, which exceeds the scope represented by 'a, so the program reports an error:

error[E0597]: `string2` does not live long enough
 --> src/main.rs:6:44
  |
5 |         let string2 = String::from("xyz");
  |             ------- binding `string2` declared here
6 |         result = longest(string1.as_str(), string2.as_str());
  |                                            ^^^^^^^ borrowed value does not live long enough
7 |     }
  |     - `string2` dropped here while still borrowed
8 |     println!("The longest string is {result}");
  |                                     -------- borrow later used here

The compiler says that string2 does not live long enough. To ensure that the result printed on line 8 is valid, string2 must remain valid until the outer scope ends. Because the function parameters and return value use the same lifetime, Rust can point out this problem.

Let’s repeat the most important point from this article one more time: the actual lifetime represented by 'a is the shorter one of the two lifetimes of x and y.

[Rust Guide] 10.5. Lifetime Definition and Significance, Borrow Checker, and Generic Lifetimes

SomeB1oody — Thu, 30 Apr 2026 17:59:19 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

10.5.1 What Is a Lifetime

Every reference in Rust has its own lifetime. The purpose of a lifetime is to keep a reference valid; in other words, it is the scope during which a reference remains valid.

In most cases, lifetimes are implicit and can be inferred. If the lifetimes of references may be related in different ways, you must annotate lifetimes manually.

Lifetimes are probably the most distinctive feature of Rust compared with other languages, so they are very hard to learn.

10.5.2 Why Lifetimes Exist

The main purpose of lifetimes is to avoid dangling references. This concept was already discussed in 4.4. Reference and Borrowing, and I’ll repeat the earlier explanation here:

When using pointers, it is very easy to trigger an error called a Dangling Pointer. It is defined as follows: a pointer references an address in memory, but that memory may already have been freed and reallocated for someone else to use. If you reference some data, the Rust compiler guarantees that the data will not go out of scope before the reference does. This is how Rust ensures that dangling references never appear.

Take this example:

fn main() {
    let r;
    { // small braces
        let x = 5;
        r = &x;
    }
    println!("{}", r);
}

In this example, r is declared first but not initialized. The purpose is to let r exist in the scope outside the small braces (as shown by the comment position). Of course, Rust has no Null value, so r cannot be used before it is initialized.
Inside the small braces, the variable x is declared and assigned the value 5. The next line assigns a reference to x to r.
After that small braces scope ends, r is printed outside it.

This code is invalid because when r is printed, x has already gone out of scope and been destroyed. So the value of r—that is, the memory address referenced by x—now points to memory that has already been freed, and the data it points to is no longer x. That creates a dangling reference, so the compiler reports an error.

Output:

error[E0597]: `x` does not live long enough
 --> src/main.rs:5:7
  |
4 |         let x = 5;
  |             - binding `x` declared here
5 |         r = &x;
  |             ^^ borrowed value does not live long enough
6 |     }
  |     - `x` dropped here while still borrowed
7 |     println!("{}", r);
  |                    - borrow later used here

The error says that the borrowed value does not live long enough. That is because when the inner-braces scope ends, x goes out of scope, but r has a larger scope and can continue to be used. To ensure program safety, any operation based on r cannot run correctly at that point.

Rust checks whether code is valid through the borrow checker.

10.5.3 The Borrow Checker

The borrow checker compares scopes to determine whether all borrows are valid. In the example above, the borrow checker sees that r is a reference to x, but r lives longer than x, so it reports an error.

How do we solve this problem? Easy: make x live at least as long as r.

fn main() {
    let x = 5;
    let r = &x;
    println!("{}", r);
}

In this case, x lives from line 2 to line 5, and r lives from line 3 to line 5. So x’s lifetime fully covers r’s lifetime, and the program does not report an error.

10.5.4 Generic Lifetimes in Functions

Take this example:

fn main() {  
    let string1 = String::from("abcd");  
    let string2 = "xyz";  

    let result = longest(string1.as_str(), string2);  
    println!("The longest string is {result}");  
}  

fn longest(x: &str, y: &str) -> &str {  
    if x.len() > y.len() {  
        x  
    } else {  
        y  
    }  
}

string1 is a String, while string2 is a string slice &str. These two values are passed into the longest function (string1 first needs to be converted to &str), and the returned value is printed.
The logic of longest is to compare the two input parameters and return the longer one.

Output:

error[E0106]: missing lifetime specifier
 --> src/main.rs:9:33
  |
9 | fn longest(x: &str, y: &str) -> &str {
  |               ----     ----     ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `x` or `y`
help: consider introducing a named lifetime parameter
  |
9 | fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
  |           ++++     ++          ++          ++

The error says that a lifetime annotation is missing, more specifically that the return type is missing a lifetime parameter. As the help text says, the function’s return type contains a borrowed value, but the function signature does not say whether that borrowed value comes from x or from y. Consider introducing a named lifetime parameter.

Look at this function again:

fn longest(x: &str, y: &str) -> &str {  
    if x.len() > y.len() {  
        x  
    } else {  
        y  
    }  
}

Clearly, the return value of this function is either x or y, but which one it is cannot be known in advance. The specific lifetimes of the two input parameters x and y are also unknown here, if we look at the function on its own. So, unlike the earlier example, we cannot compare scopes to determine whether the returned reference will remain valid. The borrow checker cannot do that either, because it does not know whether the lifetime of the return type is tied to x or to y.

In fact, even if the return value is fixed, writing it this way still causes an error:

fn longest(x: &str, y: &str) -> &str {  
    x
}

Output:

error[E0106]: missing lifetime specifier
 --> src/main.rs:9:33
  |
9 | fn longest(x: &str, y: &str) -> &str {
  |               ----     ----     ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `x` or `y`
help: consider introducing a named lifetime parameter
  |
9 | fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
  |           ++++     ++          ++          ++

The compiler still cannot tell, because the function signature does not express where the borrowed value in the return type comes from.

So this has nothing to do with the logic inside the function body; it is entirely about the function signature. How should we change it? We can follow the suggestion in the error message:

= help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `x` or `y`
help: consider introducing a named lifetime parameter
  |
9 | fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
  |           ++++     ++          ++          ++

Since it tells us to add a generic lifetime parameter, we will add one:

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {  
    if x.len() > y.len() {  
        x  
    } else {  
        y  
    }  
}

'a represents a lifetime named a. x, y, and the return type all use lifetime a, which means the lifetimes of x, y, and the return value are the same.

The phrase “the same” is not entirely precise, because the actual lifetimes of the x and y values in main differ a little. We will talk about that in the next article.

Now let’s look at the full code:

fn main() {  
    let string1 = String::from("abcd");  
    let string2 = "xyz";  

    let result = longest(string1.as_str(), string2);  
    println!("The longest string is {result}");  
}  

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {  
    if x.len() > y.len() {  
        x  
    } else {  
        y  
    }  
}

Output:

The longest string is abcd

[Rust Guide] 10.4. Trait Pt.2 - Traits as Parameters and Return Types, Trait Bounds

SomeB1oody — Mon, 27 Apr 2026 00:35:22 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

By the way, writing this article took even longer than writing the ownership chapter. Traits are truly a concept that is hard to understand.

10.4.1 Using Traits as Parameters

Let’s continue using the content from the previous article as the example:

pub trait Summary {
    fn summarize(&self) -> String;
}

pub struct NewsArticle {
    pub headline: String,
    pub location: String,
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, by {} ({})", self.headline, self.author, self.location)
    }
}

pub struct Tweet {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub retweet: bool,
}

impl Summary for Tweet {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

If we define a new function notify, which takes NewsArticle and Tweet as the two types and prints Breaking news!, followed by the return value of calling the summarize method from Summary on the parameter, there is a problem:

the function accepts two different struct types. How can we make the parameter work for two types?

Let’s think about it: what do these two structs have in common? Exactly—they both implement the Summary trait. Rust provides a solution for this situation:

pub fn notify(item: &impl Summary) {  
    println!("Breaking news! {}", item.summarize());  
}

Just write the parameter type as impl some_trait. Since both of these structs implement the Summary trait, we write impl Summary. And because this function does not need ownership of the data, we write it as a reference: &impl Summary. If some other data type also implements Summary, it can be passed in as well.

The impl trait syntax is suitable for simple cases. For more complex cases, trait bound syntax is usually used.

Using the same code, but written with trait bounds:

pub fn notify<T: Summary>(item: &T) {  
    println!("Breaking news! {}", item.summarize());  
}

These two forms are equivalent.

However, this simple example does not show the advantages of trait bounds very well. Let’s look at another example. Suppose I want to design a new notify1 function. It takes two parameters, and the content after Breaking news! is the return value of calling summarize on each parameter.

Trait-bound version:

pub fn notify1<T: Summary>(item1: &T, item2: &T) {  
    println!("Breaking news! {} {}", item1.summarize(), item2.summarize());  
}

impl trait version:

pub fn notify1(item1: &impl Summary, item2: &impl Summary) {  
    println!("Breaking news! {} {}", item1.summarize(), item2.summarize());  
}

Clearly, the former function signature is easier to write and more intuitive than the latter.

In fact, impl trait is just syntax sugar for trait bounds, so it is understandable that it is not suitable for complex cases.

So what if the notify function needs its parameter to implement both the Display trait and the Summary trait? In other words, how do you write two or more trait bounds?

Example:

pub fn notify_with_display<T: Summary + std::fmt::Display>(item: &T) {  
    println!("Breaking news! {}", item);  
}

Use + to connect each trait bound.

Another point: because Display is not in the prelude, when writing it you need to spell out its path. You can also import Display at the top of the code first, like this: use std::fmt::Display. Then you can write Display directly in the trait bounds:

use std::fmt::Display;

pub fn notify_with_display<T: Summary + Display>(item: &T) {  
    println!("Breaking news! {}", item);  
}

Don’t forget that impl trait is also syntax sugar, and in that syntax sugar you also connect trait bounds with +:

use std::fmt::Display;

pub fn notify_with_display(item: &(impl Summary + Display)) {  
    println!("Breaking news! {}", item);  
}

This form has one drawback: if there are too many trait bounds, the large amount of constraint information will reduce the readability of the function signature. To solve this, Rust provides an alternative syntax: write the trait bounds after the function signature using a where clause.

Here is the ordinary syntax for multiple trait bounds:

use std::fmt::Display;  
use std::fmt::Debug;

pub fn special_notify<T: Summary + Display, U: Summary + Debug>(item1: &T, item2: &U) {  
    println!("Breaking news! {} and {}", item1.summarize(), item2.summarize());  
}

The same code rewritten with a where clause:

use std::fmt::Display;  
use std::fmt::Debug;

pub fn special_notify<T, U>(item1: &T, item2: &U)   
where  
    T: Summary + Display,  
    U: Summary + Debug,  
{  
    println!("Breaking news! {} and {}", item1.summarize(), item2.summarize());  
}

This syntax is very similar to C#.

10.4.2 Using Traits as Return Types

Just like using traits as parameters, using traits as return values can also use impl trait. For example:

fn returns_summarizable() -> impl Summary {  
    Tweet {  
        username: String::from("horse_ebooks"),  
        content: String::from(  
            "of course, as you probably already know, people",  
        ),  
        reply: false,  
        retweet: false,  
    }  
}

This syntax has a drawback: if the return type implements a certain trait, then you must ensure that all possible return values of this function/method are only one type. That is because the impl form has some limitations in how it works, which is why Rust does not support it in every case. But Rust does support dynamic dispatch, which will be covered later.

For example:

fn returns_summarizable(flag:bool) -> impl Summary {  
    if flag {  
        Tweet {  
        username: String::from("horse_ebooks"),  
        content: String::from(  
            "of course, as you probably already know, people",  
        ),  
        reply: false,  
        retweet: false,  
        }  
    } else {  
        NewsArticle {  
            headline: String::from("Penguins win the Stanley Cup Championship!"),  
            location: String::from("Pittsburgh, PA, USA"),  
            author: String::from("Iceburgh, Scotland"),  
            content: String::from(  
                "The Pittsburgh Penguins once again are the best \  
                hockey team in the NHL.",  
            ),  
        }  
    }  
}

There are two possible return types depending on the value of flag: Tweet and NewsArticle. At that point, the compiler will report an error:

error[E0308]: `if` and `else` have incompatible types
  --> src/lib.rs:42:9
   |
32 | /       if flag {
33 | | /         Tweet {
34 | | |         username: String::from("horse_ebooks"),
35 | | |         content: String::from(
36 | | |             "of course, as you probably already know, people",
...  | |
39 | | |         retweet: false,
40 | | |         }
   | | |_________- expected because of this
41 | |       } else {
42 | | /         NewsArticle {
43 | | |             headline: String::from("Penguins win the Stanley Cup Championship!"),
44 | | |             location: String::from("Pittsburgh, PA, USA"),
45 | | |             author: String::from("Iceburgh, Scotland"),
...  | |
49 | | |             ),
50 | | |         }
   | | |_________^ expected `Tweet`, found `NewsArticle`
51 | |       }
   | |_______- `if` and `else` have incompatible types
   |
help: you could change the return type to be a boxed trait object
   |
31 | fn returns_summarizable(flag:bool) -> Box<dyn Summary> {
   |                                       ~~~~~~~        +
help: if you change the return type to expect trait objects, box the returned expressions
   |
33 ~         Box::new(Tweet {
34 |         username: String::from("horse_ebooks"),
...
39 |         retweet: false,
40 ~         })
41 |     } else {
42 ~         Box::new(NewsArticle {
43 |             headline: String::from("Penguins win the Stanley Cup Championship!"),
...
49 |             ),
50 ~         })
   |

The error message says that the return types of if and else are incompatible, meaning they are not the same type.

Trait Bound Example

Do you still remember the code for comparing numbers that was mentioned in 10.2. Generics? I’ll paste it here:

fn largest<T>(list: &[T]) -> T{  
    let mut largest = list[0];  
    for &item in list{  
        if item > largest{  
            largest = item;  
        }  
    }  
    largest  
}

I’ll also paste the error that occurred at that time:

error[E0369]: binary operation `>` cannot be applied to type `T`
 --> src/main.rs:4:17
  |
4 |         if item > largest{
  |            ---- ^ ------- T
  |            |
  |            T
  |
help: consider restricting type parameter `T`
  |
1 | fn largest<T: std::cmp::PartialOrd>(list: &[T]) -> T{
  |             ++++++++++++++++++++++

Now that we have learned traits, does your understanding of this code and its error message feel different?

Let’s start by analyzing the error message. The error says that the comparison operator > cannot be applied to type T. The help line below says to consider restricting type parameter T, and further down it gives the concrete approach: add std::cmp::PartialOrd after T (in the trait bound, you only need to write PartialOrd because it is in the prelude, so the full path is not needed). This is actually the trait used for comparisons. Try modifying it according to the hint:

fn largest<T: PartialOrd>(list: &[T]) -> T{  
    let mut largest = list[0];  
    for &item in list{  
        if item > largest{  
            largest = item;  
        }  
    }  
    largest  
}

It still reports an error:

error[E0508]: cannot move out of type `[T]`, a non-copy slice
 --> src/main.rs:2:23
  |
2 |     let mut largest = list[0];
  |                       ^^^^^^^
  |                       |
  |                       cannot move out of here
  |                       move occurs because `list[_]` has type `T`, which does not implement the `Copy` trait
  |
help: if `T` implemented `Clone`, you could clone the value
 --> src/main.rs:1:12
  |
1 | fn largest<T: std::cmp::PartialOrd>(list: &[T]) -> T{
  |            ^ consider constraining this type parameter with `Clone`
2 |     let mut largest = list[0];
  |                       ------- you could clone this value
help: consider borrowing here
  |
2 |     let mut largest = &list[0];
  |                       +

But the error is different this time: the element cannot be moved out of list, because T in list does not implement the Copy trait. The help below says that if T implements the Clone trait, consider cloning the value. There is also another help below that suggests borrowing.

Based on the above information, there are three solutions:

Add the Copy trait to the generic type
Use cloning, which means adding the Clone trait to the generic type
Use borrowing

Which solution should we choose? It depends on your needs. I want this function to handle collections of numbers and characters. Since numbers and characters are stored on the stack, they both implement the Copy trait, so it is enough to add Copy to the generic type:

fn largest<T: PartialOrd + Copy>(list: &[T]) -> T{    
    let mut largest = list[0];    
    for &item in list{    
        if item > largest{    
            largest = item;    
        }    
    }    
    largest    
}  

fn main() {  
    let number_list = vec![34, 50, 25, 100, 65];  
    let result = largest(&number_list);  
    println!("The largest number is {}", result);  

    let char_list = vec!['y', 'm', 'a', 'q'];  
    let result = largest(&char_list);  
    println!("The largest char is {}", result);  
}

Output:

The largest number is 100
The largest char is y

What if I want this function to compare a String collection? Since String is stored on the heap, it does not implement the Copy trait, so the idea of adding Copy to the generic type does not work.

Then try cloning, which means adding the Clone trait to the generic type:

fn largest<T: PartialOrd + Clone>(list: &[T]) -> T{    
    let mut largest = list[0].clone();    
    for &item in list.iter() {    
        if item > largest{    
            largest = item;    
        }    
    }    
    largest    
}  

fn main() {  
    let string_list = vec![String::from("dev1ce"), String::from("Zywoo")];  
    let result = largest(&string_list);  
    println!("The largest string is {}", result);  
}

Output:

error[E0507]: cannot move out of a shared reference
 --> src/main.rs:3:18
  |
3 |     for &item in list.iter() {  
  |          ----    ^^^^^^^^^^^
  |          |
  |          data moved here
  |          move occurs because `item` has type `T`, which does not implement the `Copy` trait
  |
help: consider removing the borrow
  |
3 -     for &item in list.iter() {  
3 +     for item in list.iter() {  
  |

The error says that data cannot be moved because this form requires Copy, which String does not provide. What should we do?

Then do not move the data; do not use pattern matching. Remove the & in front of item, so item changes from T to an immutable reference &T. Then use the dereference operator * during comparison to dereference &T back to T and compare it with largest (the code below uses this approach), or add & in front of largest to make it &T. In short, the two values being compared must have the same type:

fn largest<T: PartialOrd + Clone>(list: &[T]) -> T{    
    let mut largest = list[0].clone();    
    for item in list.iter() {    
        if *item > largest{    
            largest = item.clone();    
        }    
    }    
    largest    
}

fn main() {  
    let string_list = vec![String::from("dev1ce"), String::from("Zywoo")];  
    let result = largest(&string_list);  
    println!("The largest string is {}", result);  
}

Remember that T does not implement the Copy trait, so when assigning to largest, you need to use the clone method.

Output:

The largest string is dev1ce

This form is written this way because the return value is T. If you change the return value to &T, then cloning is no longer needed:

fn largest<T: PartialOrd>(list: &[T]) -> &T{      
    let mut largest = &list[0];      
    for item in list.iter() {      
        if item > largest{      
            largest = item;      
        }      
    }      
    largest      
}  

fn main() {  
    let string_list = vec![String::from("dev1ce"), String::from("Zywoo")];  
    let result = largest(&string_list);  
    println!("The largest string is {}", result);  
}

But remember that when initializing largest, you must set it to &T, so you need to add & in front of list[0] to make it a reference. Also, when comparing, you cannot use the method of dereferencing item; instead, you need to add & in front of largest.

10.4.3 Conditionally Implementing Methods with Trait Bounds

If you use trait bounds on an impl block with generic type parameters, you can conditionally implement methods for types that implement specific traits.

For example:

use std::fmt::Display;  

struct Pair<T> {  
    x: T,  
    y: T,  
}  

impl<T> Pair<T> {  
    fn new(x: T, y: T) -> Self {  
        Self { x, y }  
    }  
}  

impl<T: Display + PartialOrd> Pair<T> {  
    fn cmp_display(&self) {  
        if self.x >= self.y {  
            println!("The largest member is x = {}", self.x);  
        } else {  
            println!("The largest member is y = {}", self.y);  
        }  
    }  
}

No matter what the concrete type of T is, the new function will always exist on Pair. But the cmp_display method exists only when T implements both Display and PartialOrd.

You can also conditionally implement one trait for any type that implements another trait. Implementing a trait for all types that satisfy a trait bound is called a blanket implementation.

Take the standard library’s to_string function as an example:

impl<T: Display> ToString for T {
    // ......
}

This means that ToString is implemented for all types that satisfy the Display trait, which is what a blanket implementation is: any type that implements Display can call methods on ToString.

Using an integer as an example:

let s = 3.to_string();

This works because i32 implements the Display trait, so it can call the to_string method from ToString.

[Rust Guide] 10.3. Trait Pt.1 - Trait Definitions, Bounds, and Implementation

SomeB1oody — Mon, 27 Apr 2026 00:28:42 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

10.3.1 What Is a Trait

Trait means feature or characteristic. Traits are used to describe to the Rust compiler what capabilities a type has and which behaviors it can share with other types. Traits define shared behavior in an abstract way.

There is also the concept of trait bounds, which can constrain a generic type parameter to a type that implements a specific behavior. In other words, it requires the generic type parameter to implement certain traits.

Traits in Rust are somewhat similar to interfaces in other languages, but there are still differences.

10.3.2 Defining a Trait

The behavior of a type is made up of the methods that the type itself can call. Sometimes different types have the same methods, and in that case we say those types share the same behavior. Traits provide a way to group methods together, thereby defining the behavior required to achieve a certain purpose.

Use the trait keyword to define a trait. Inside the trait definition, there are only method signatures, no concrete implementations
A trait can have multiple methods, and each method is written on its own line and ends with ;
The type implementing that trait must provide concrete method implementations, which means method bodies are required

For example:

pub trait Summary {
    fn summarize(&self) -> String;
}

Adding pub before trait makes it public. The trait is named Summary, and it contains a method signature called summarize. Aside from &self, it has no other parameters, the return type is String, and the signature ends with ;. There is no method body, so there is no concrete implementation. Of course, a trait can contain many method signatures:

pub trait Summary {
    fn summarize(&self) -> String;
    fn summarize1(&self) -> String;
    fn summarize2(&self) -> String;
    //......
}

10.3.3 Implementing a Trait for a Type

Implementing a trait for a type is very similar to implementing methods for a type, but there are also differences.

The syntax for implementing methods for a type is to follow the impl keyword with the type:

impl Yyyy {....}

Implementing a trait for a type looks like this:

impl Xxxx for Yyyy {....}

Xxxx refers to the trait name
Yyyy refers to the type name
Inside the braces, you need to write the concrete implementations for the trait’s method signatures

For example (lib.rs):

pub trait Summary {
    fn summarize(&self) -> String;
}

pub struct NewsArticle {
    pub headline: String,
    pub location: String,
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, by {} ({})", self.headline, self.author, self.location)
    }
}

pub struct Tweet {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub retweet: bool,
}

impl Summary for Tweet {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

The struct NewsArticle represents a news article. It has four fields: headline for the title, location for the location, author for the author, and content for the content
The struct Tweet represents a tweet on X (formerly Twitter). It has four fields: username, content, reply, and retweet

These two struct types are certainly different, and most of their fields are different too. But they can both have the same behavior—providing a Summary—so Summary is implemented separately for both types.

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, by {} ({})", self.headline, self.author, self.location)
    }
}

This block implements the trait for NewsArticle. Because the trait definition includes the summarize method signature, a concrete implementation must be written here: use the format! macro to combine self.headline, self.author, and self.location into a string and return it.

impl Summary for Tweet {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

This block implements the trait for Tweet as well, again providing the concrete implementation of summarize: use the format! macro to combine self.username and self.content into a string and return it.

Now let’s move to main.rs and look at how the instances are called:

use RustStudy::{Summary, Tweet};

fn main() {
    let tweet = Tweet {
        username: String::from("horse_ebooks"),
        content: String::from(
            "of course, as you probably already know, people",
        ),
        reply: false,
        retweet: false,
    };

    println!("1 new tweet: {}", tweet.summarize());
}

Remember that our code is written in lib.rs, before using something in main.rs, you need to bring it into scope first. The syntax is:

use your_package_name::...::the_module_you_need;

Your package name is the project name in Cargo.toml; just copy it from there.

Summary is imported because the summarize method under the Summary trait is used. Tweet is imported because the Tweet struct is used.

Look at the output:

1 new tweet: horse_ebooks: of course, as you probably already know, people

10.3.4 Trait Constraints

The prerequisites for implementing a trait for a type are:

The type itself (for example Tweet) or the trait itself (for example letting Vector implement a local Summary) must be defined in the local crate
You cannot implement an external trait for an external type. For example, in a local crate implementing the standard library’s Display trait for the standard library’s Vector This restriction is part of the language’s coherence rules. More specifically, it is the orphan rule, so named because the parent type is not defined in the current crate. This rule ensures that other people’s code cannot arbitrarily break your code, and vice versa. Without this rule, two crates could implement the same trait for the same type, and Rust would not know which implementation to use.

10.3.5 Default Implementations

Sometimes it is very useful to provide default behavior for some or all methods in a trait. This lets us avoid writing custom behavior for every single type implementation. We can still implement trait methods for specific types.

When implementing a trait for certain types, we can choose whether to keep or override each method’s default implementation.

The previous version was:

pub trait Summary {
    fn summarize(&self) -> String;
}

The previous version only wrote the method signature and did not provide an implementation, but in fact a default implementation can be added:

Default implementation:

pub trait Summary {
    fn summarize(&self) -> String {
        String::from("(Read more...)")
    }
}

The default implementation here simply returns the string "(Read more...)".

Because this method already has a default implementation in the trait, a concrete type can use that default implementation directly instead of providing its own.

Using NewsArticle as an example, it originally had its own implementation (also called an override of the default implementation):

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, by {} ({})", self.headline, self.author, self.location)
    }
}

If you delete this concrete implementation, NewsArticle will use the default implementation:

impl Summary for NewsArticle {}

There is one more thing to know: a method with a default implementation can call other methods in the trait, even if those methods do not have default implementations:

pub trait Summary {
    fn summarize_author(&self) -> String;
    fn summarize(&self) -> String {
        format!("(Read more from {}...)", self.summarize_author())
    }
}

The default implementation of summarize calls summarize_author, even though summarize_author is only a signature and has no concrete implementation. But if you want to implement summarize for a type, you first need to implement summarize_author:

impl Summary for NewsArticle {
    fn summarize_author(&self) -> String {
        format!("@{}", self.author)
    }
}

PS: Since NewsArticle uses the default implementation of summarize, there is no need to write a default implementation of summarize here.

One thing to note about this style: you cannot call the default implementation from within an overridden method implementation.

[Rust Guide] 10.2. Generics

SomeB1oody — Mon, 27 Apr 2026 00:04:31 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

10.2.1 What Are Generics

The main purpose of generics is to improve code reusability. They are suitable for handling repeated-code problems, and can also be seen as separating data from algorithms.

Generics are abstract substitutes for concrete types or other attributes. In other words, generic code is not the final code you write; it is more like a template with some placeholders.

The compiler replaces those placeholders with concrete types at compile time. Let’s look at an example:

fn largest<T>(list:&[T]) -> T {
//......
}

This function definition uses a generic type parameter. T is the so-called “placeholder.” When you write the code, T can represent any type, but during compilation the compiler replaces T with a concrete type based on the actual usage. This process is called monomorphization.

T is the generic type parameter. In fact, you can use any valid identifier as the type-parameter name, but by convention people usually use an uppercase T (for Type). When choosing a generic type-parameter name, it is usually very short; one letter is often enough. If you really want to make it longer, use camel-case naming.

10.2.2 Generics in Function Definitions

When defining a function with generics, you need to place the generic type parameter in the function signature. Generic type parameters are usually used to specify parameter and return types.

Using the code from the previous article as an example, here it is with a small generic modification:

fn largest<T>(list: &[T]) -> T{  
    let mut largest = list[0];  
    for &item in list{  
        if item > largest{  
            largest = item;  
        }  
    }  
    largest  
}

You can understand the whole function definition like this: the function largest has a generic type parameter T, it accepts a slice as its argument, the slice’s elements are of type T, and the return value is also of type T.

Try compiling it, and the output is:

error[E0369]: binary operation `>` cannot be applied to type `T`
 --> src/main.rs:4:17
  |
4 |         if item > largest{
  |            ---- ^ ------- T
  |            |
  |            T
  |
help: consider restricting type parameter `T`
  |
1 | fn largest<T: std::cmp::PartialOrd>(list: &[T]) -> T{
  |             ++++++++++++++++++++++

For now, we won’t discuss the reason or how to fix it. You only need to know that this is roughly how generic parameters are written. Later articles will explain how to specify a particular trait.

10.2.3 Generics in struct Definitions

Generic type parameters defined in structs are mainly used in their fields. For example:

struct Point<T> {   
    x: T,  
    y: T,  
}  

fn main() {  
    let integer = Point { x: 5, y: 10 };  
    let float = Point { x: 1.0, y: 4.0 };  
}

Add <> after the struct name and write the generic parameter name inside it, and that generic type can be applied to each field in the struct.

In main, this struct is instantiated. The two fields in integer are both i32, and the two fields in float are both f64. Because x and y are both declared as T, the instantiated x and y must also be the same type. The two types must remain consistent.

What if I want x and y to be two different types? Easy: declare two generic type parameters.

struct Point<T, U> {   
    x: T,  
    y: U,  
}  

fn main() {  
    let integer = Point { x: 5, y: 1.0 };  
    let float = Point { x: 1.0, y: 40 };  
}

At this point, the instantiated x and y can be different types, of course they can also be the same type.

Note that although multiple generic type parameters are allowed, too many generics will reduce readability. Usually, that means the code should be reorganized into more, smaller units.

10.2.4 Generics in enum Definitions

Much like structs, generic type parameters in enums are mainly used in their variants, allowing enum variants to hold generic data types. The most common examples are Option<T> and Result<T, E>.

For example:

enum Option<T> {  
    Some(T),  
    None,  
}  

enum Result<T, E> {  
    Ok(T),  
    Err(E),  
}

In the Option enum, Some(T) is the variant that holds a value of type T, while the None variant means it holds no value. Because the Option enum uses generics, Option<T> can represent a possible value no matter what type that value is
Likewise, an enum can use multiple generic type parameters. For example, the Result enum uses T and E: the Ok variant stores T, and the Err variant stores E

10.2.5 Generics in Method Definitions

Methods can be attached to enums or structs. Since enums and structs can use generic parameters, methods can too, as shown here:

struct Point<T> {   
    x: T,  
    y: T,  
}  

impl<T> Point<T> {  
    fn x(&self) -> &T {  
        &self.x  
    }  
}

The x method is essentially a getter. When implementing methods for Point<T>, you need to add <T> after the impl keyword. This indicates that the implementation is for generic T, not for some concrete type.

Of course, if you are implementing a method for a specific type, you do not need that:

impl Point<i32> {  
    fn x1(&self) -> &i32 {  
        &self.x  
    }  
}

The x1 method exists only on the concrete type Point<i32>, and other Point<T> types do not have this method, similar to specialization and partial specialization in C++.

Another important point is that the generic type parameters in the struct can differ from the generic type parameters in the method. For example:

struct Point<T, U> {   
    x: T,  
    y: U,  
}  

impl<T, U> Point<T, U> {  
    fn mixup<V, W>(self, other: Point<V, W>) -> Point<T, W> {  
        Point {  
            x: self.x,  
            y: other.y,  
        }  
    }  
}  

fn main() {  
    let p1 = Point { x: 5, y: 10.4 };  
    let p2 = Point { x: "Hello", y: 'c' };  
    let p3 = p1.mixup(p2);  
    println!("p3.x = {}, p3.y = {}", p3.x, p3.y);  
}

The method mixup is implemented for Point<T, U>. It has two generic type parameters, V and W. The two type parameters in the method are different from the two type parameters in Point, although the actual types may also end up being the same. The second parameter of mixup is other, whose type is also Point, but that Point does not necessarily use the same data types as the Point referred to by self, so two new generic type parameters are needed. Looking at the return type, it is Point<T, W>: T comes from Point<T, U>, and W comes from Point<V, W>.

Now look at main: first p1 is declared, and both of its fields are i32; then p2 is declared, and its two fields are &str (string slice) and char (a single character, represented with ''). Then mixup is used. p1 corresponds to Point<T, U>, and p2 corresponds to Point<V, W>. From their field types, we can infer that T is i32, U is i32, V is &str, and W is char. The return type of mixup is Point<T, W>, which in this example becomes Point<i32, char>.

Output:

p3.x = 5, p3.y = c

10.2.6 Performance of Generic Code

Code written with generics runs just as fast as code written with concrete types. Rust performs monomorphization at compile time, replacing generic types with concrete types, so there is no type-substitution process during execution.

For example:

fn main() {
    let integer = Some(5);
    let float = Some(5.0);
}

Here integer is Option<i32>, and float is Option<f64>. During compilation, the compiler expands Option<T> into Option_i32 and Option_f64:

enum Option_i32 {
    Some(i32),
    None,
}

enum Option_f64 {
    Some(f64),
    None,
}

In other words, the generic definition Option<T> is replaced by two concrete type definitions.

The monomorphized main function also becomes this:

enum Option_i32 {
    Some(i32),
    None,
}

enum Option_f64 {
    Some(f64),
    None,
}

fn main(){
    let integer = Option_i32::Some(5);
    let float = Option_f64::Some(5.0);
}

[Rust Guide] 10.1. Extract Function to Eliminate Repeated Code

SomeB1oody — Mon, 27 Apr 2026 00:01:39 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

10.1.1 Repeated Code

Let’s look at an example:

fn main(){  
    let number_list = vec![1,2,3,4,5];  
    let mut largest = number_list[0];  
    for &item in number_list.iter(){  
        if item > largest{  
            largest = item;  
        }  
    }  
    println!("The largest number is {}", largest);  
}

The purpose of this program is to find the largest value in a Vector. Its logic is easy to understand: take the first element as a temporary largest value, then use a loop to compare every element in the Vector. If the current element is greater than the value stored as the largest, assign the current element to largest.

Output:

The largest number is 5

If a new requirement is added at this point and you need to find the largest value in another Vector, you can still write it using the same logic:

fn main(){  
    let number_list = vec![1,2,3,4,5];  
    let mut largest = number_list[0];  
    for &item in number_list.iter(){  
        if item > largest{  
            largest = item;  
        }  
    }  
    println!("The largest number is {}", largest);  

    let number_list = vec![6,7,8,9,10];  
    let mut largest = number_list[0];  
    for &item in number_list.iter(){  
        if item > largest{  
            largest = item;  
        }  
    }  
    println!("The largest number is {}", largest);  
}

But you can see that this way produces far too much repeated code.

Repeated code is easy to get wrong. Once we need to change the logic, we have to make the same change in multiple places.

So it is highly recommended to create abstractions by defining functions. The code looks like this:

fn largest(list: &[i32]) -> i32{  
    let mut largest = list[0];  
    for &item in list.iter(){  
        if item > largest{  
            largest = item;  
        }  
    }  
    largest  
}  

fn main(){  
    let number_list = vec![1,2,3,4,5];  
    let largest_num = largest(&number_list);  
    println!("The largest number is {}", largest_num);  

    let number_list = vec![6,7,8,9,10];  
    let largest_num = largest(&number_list);  
    println!("The largest number is {}", largest_num);  
}

This declares a function called largest. It takes a slice whose element type is i32, and returns an i32. The logic inside the function is the same as above. Note that the parameter &[i32] is a slice, which is essentially a reference. The specific introduction to slices is in 4.5. Slices (Slice), so I won’t go into it here.

This function can also be written in the following way without changing the logic:

fn largest(list: &[i32]) -> i32{  
    let mut largest = list[0];  
    for &item in list{  
        if item > largest{  
            largest = item;  
        }  
    }  
    largest  
}

Compared with the previous version, this one removes the explicit iterator call .iter(), but it does not affect the code’s behavior, because the slice reference itself implements IntoIterator, so for can iterate over list directly. These two forms are semantically equivalent. Rust’s for loop automatically calls iter() for slices, so the explicit iterator call can be omitted. Which style you choose mainly depends on code style and personal preference.

There is another way:

fn largest(list: &[i32]) -> i32{  
    let mut largest = list[0];  
    for item in list{  
        if *item > largest{  
            largest = *item;  
        }  
    }  
    largest  
}

The biggest difference between this version and the previous two is that it explicitly dereferences item (*item) in order to compare its value.

In the previous two versions, destructuring via dereferencing pattern matching was used. You can think of it like this: &item = &i32, so if both sides drop the &, then item = i32. largest is also of type i32, so the two types match and can be compared directly. Naturally, there is no need to dereference later. If item does not have & in front of it, then item is of type &i32, while largest is of type i32. The two types cannot be compared directly, so you must first dereference it, which means adding * in front of item.

Output:

The largest number is 5
The largest number is 10

10.1.2 Steps to Eliminate Repetition

Identify repeated code
Create a function, extract the repeated code into the function body, and specify the function’s inputs and return value in the function signature
Replace the repeated code with function calls

[Rust Guide] 9.4. When Should You Use Panic!

SomeB1oody — Sun, 26 Apr 2026 03:34:11 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

9.4.1 General Principles

Chapter 9.1, “Unrecoverable Errors and panic!”, already explained that Rust has two kinds of errors: recoverable and unrecoverable.

Calling panic! is equivalent to an unrecoverable error. Returning a Result type means the error is propagated, and such an error is recoverable.

If you think you can decide on behalf of the caller of your code that a situation is unrecoverable, then you can write panic!.

If your function returns Result, you are effectively giving the caller of the code the right to decide how to handle the error. The caller can then decide whether to recover from it, or it can consider the error unrecoverable and call panic! itself.

In short, if you are defining a function that may fail, prefer returning Result. If you believe a situation is definitely unrecoverable, use panic!.

9.4.2 Scenarios Where `panic!` Is Appropriate

When writing example code to demonstrate certain concepts, panic! is acceptable. In this kind of program, error handling often uses unwrap-style approaches that can trigger a panic. Here, unwrap acts like a placeholder, and code for different errors can later be written separately for each function.

You can use panic! when writing prototype code. At that stage, you may not yet know how to handle errors, and the unwrap and expect methods are very convenient during prototyping because they can trigger panics and leave clear markers in the code. Later, you can use those markers to handle the errors more specifically.

You can use panic! when writing test code. If a method call fails in test code, the entire test should be considered a failure, and failure is exactly what panic! can mark.

9.4.3 You Know Better Than the Compiler

Sometimes you can be certain that a function call will return Ok and will never panic. In that case, you can use unwrap. However, because the return type is something like Result, the compiler still thinks it may fail, while you know it cannot.

Take a look at an example:

use std::net::IpAddr;
fn main(){
    let home: IpAddr = "127.0.0.1".parse().unwrap();
}

This example uses the IpAddr enum. In main, the string "127.0.0.1" is parsed. We know that "127.0.0.1" is a valid IP address, so the return value is definitely Ok, which means unwrap can be used here and will never panic.

9.4.5 Guiding Advice for Error Handling

When your code may end up in a bad state, it is usually best to use panic!. A bad state means that certain assumptions, guarantees, agreements, or invariants have been broken.

For example, invalid values, conflicting values, or missing values are passed into the code. And any of the following is true:

This bad state is unexpected.
Code after this point cannot continue to run if it is in this bad state.
There is no good way to encode the information in the type being used.

Let’s look at some concrete scenarios:

A meaningless parameter value is passed in: panic!
External uncontrollable code returns an invalid state and you cannot fix it: panic!
If failure is expected, such as parsing a string into a number: Result
When your code operates on a value, you should first verify that the value is valid. If it is not: panic! This is mainly for security reasons, because attempting to operate on an invalid value may expose vulnerabilities in the code. This is also why the standard library reports an error when code tries to access out of bounds: trying to access memory that does not belong to the current data structure is a common security problem. In addition, functions usually have certain contracts: they can run correctly only when the input satisfies specific conditions, and when those contracts are violated, they should panic. Breaking those contracts often indicates a bug on the caller’s side, and the resulting error should not be left for the caller to fix. It should be dealt with immediately by panicking.

9.4.6 Creating a Custom Type for Validation

Take the number guessing game from Chapter 2 as an example. Some code has been omitted:

fn main() {
    loop {
        // --snip--

        let guess: i32 = match guess.trim().parse() {
            Ok(num) => num,
            Err(_) => continue,
        };

        if guess < 1 || guess > 100 {
            println!("The secret number will be between 1 and 100.");
            continue;
        }

        match guess.cmp(&secret_number) {
            // --snip--
    }
}

The original code has been changed a little:

The type of guess has been changed from u32 to i32, so negative numbers can be accepted.
If the user enters a value less than 1 or greater than 100, the user is told that the secret number is between 1 and 100.

If parsing the string into an integer fails, continue is triggered to start the next iteration. If the number is outside the range 1 to 100, continue is triggered again. For this small program, the validation can be written directly inside main. In a large project, however, if every function needs validation, writing the validation logic over and over again inside each function would be quite troublesome.

In such cases, you can create a new type and put the validation logic into the constructor for that type. In this way, only values that pass validation can successfully create an instance, and you do not need to worry about whether the values you receive are valid later on.

Look at the example:

pub struct Guess {
    value: i32,
}

impl Guess {
    pub fn new(value: i32) -> Guess {
        if value < 1 || value > 100 {
            panic!("Guess value must be between 1 and 100, got {value}.");
        }

        Guess { value }
    }

    pub fn value(&self) -> i32 {
        self.value
    }
}

fn main() {
    loop {
        // --snip--

        let guess: i32 = match guess.trim().parse() {
            Ok(num) => num,
            Err(_) => continue,
        };

        let guess = Guess::new(guess);

        match guess.value().cmp(&secret_number) {
            // --snip--
    }
}

new is the instance constructor. If the value is not between 1 and 100, it will panic!. If no panic occurs, a Guess instance is created and the value field is set to the value that was passed in.

There is also a method called value, which extracts the value of the value field from the struct and returns it.

In the main function below, you can remove the validation that checks whether the value is between 1 and 100 and instead use the Guess::new constructor to perform the validation.

If you need the actual value of guess, for example when using match, you can use the value method to get it.

[Rust Guide] 9.3. Result Enum and Recoverable Errors Pt. 2 - Error Propagation, Question Mark Operator, and Chained Calls

SomeB1oody — Sun, 26 Apr 2026 03:29:35 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

9.3.1 Propagating Errors

When a function you write contains calls that may fail, you can either handle the error inside the function or return the error to the caller and let the caller decide how to handle it.

Take a look at an example:

use std::fs::File;
use std::io::{self, Read};

fn read_username_from_file() -> Result<String, io::Error> {
    let f = File::open("6657.txt");

    let mut f = match f {
        Ok(file) => file,
        Err(e) => return Err(e),
    };

    let mut s = String::new();
    match f.read_to_string(&mut s) {
        Ok(_) => Ok(s),
        Err(e) => Err(e),
    }
}

fn main() {
    let result = read_username_from_file();
}

The intention of this code is to read a username from a file:

Its return type is the Result enum. The two type parameters, T and E, correspond to String and io::Error. In other words, when everything goes smoothly, the function returns the Ok variant of Result, and the Ok value contains a String username. If a problem occurs, the function returns the Err variant of Result, and that variant contains an instance of io::Error.
Looking at the function body, it first uses File::open to try to open a file and assigns the Result to f. Then it performs a match on f (the second f is made mutable because read_to_string below uses &mut self). If the operation succeeds, it returns file and assigns the value to f. If the operation fails, it returns Err(e). Here, e is the specific error that occurred, and when the function body encounters the return keyword, execution ends immediately and the value after return — namely Err(e) — is returned. The error type happens to be io::Error, so the return value matches the Result type parameters.
If File::open succeeds, the function then creates a mutable String called s and calls read_to_string to read the file contents into s. Of course, read_to_string may also fail, so a match expression follows it.
This match expression has no semicolon at the end, and it is also the last expression in the function, so it becomes the function’s return value. The match has two branches. If the operation succeeds, it returns the Ok variant of Result and wraps the String value s inside it. If the operation fails, it returns the Err variant, wraps the error e inside it, and returns it. The return type of read_to_string also happens to be io::Error, so the return value matches the Result type parameters.

9.3.2 The `?` Operator

Error propagation is very common in Rust, so Rust provides the ? operator specifically to simplify the process.

Use ? to achieve the same effect as the example above:

use std::fs::File;
use std::io::{self, Read};

fn read_username_from_file() -> Result<String, io::Error> {
    let mut f = File::open("6657.txt")?;
    let mut s = String::new();
    f.read_to_string(&mut s)?;
    Ok(s)
}

fn main() {
    let result = read_username_from_file();
}

For the first ? (line 5): File::open returns a Result, and adding ? means that if File::open returns Ok, the value inside Ok becomes the result of the expression and is assigned to f. If File::open returns Err, then function execution stops and Err together with the wrapped error information is returned as the function’s return value — that is, return Err(e). In other words, the effect of line 5 is equivalent to:

let f = File::open("6657.txt");
let mut f = match f {
    Ok(file) => file,
    Err(e) => return Err(e),
};

For the second ? (line 7): if read_to_string succeeds, execution continues. The successful return value is not actually used in the code, but if it fails, function execution stops and Err together with the wrapped error information is returned as the function’s return value — that is, return Err(e).
If everything succeeds up to that point, the expression Ok(s) wraps the String value s in Ok and returns it.

To summarize: when ? is used on a Result, if it is Ok, the value inside Ok becomes the result of the expression and execution continues; if the operation fails, that is, if it is Err, then Err becomes the return value of the entire function, just like using return.

9.3.3 `?` and the `from` Function

Rust provides the from function. It comes from the std::convert::From trait, and its job is to convert between errors, turning one error type into another. Errors received by ? are implicitly handled by from, which looks at the error type the current function is supposed to return and converts to that type.

Using the code from just now as an example, the return value of read_username_from_file is Result<String, io::Error>, so from can see that the function needs io::Error as the error return type and will convert different error types into io::Error. In this case, all errors inside the function body happen to already be io::Error, so no conversion is needed.

This feature is very useful when different error causes need to be mapped into the same error type. The prerequisite is that the involved error types implement From trait so they can be converted into the error type being returned.

9.3.4 Chained Calls

In fact, the previous example can be optimized further by using chained calls. The optimized code looks like this:

use std::fs::File;
use std::io::{self, Read};

fn read_username_from_file() -> Result<String, io::Error> {
    let mut s = String::new();
    File::open("6657.txt")?.read_to_string(&mut s)?;
    Ok(s)
}

fn main() {
    let result = read_username_from_file();
}

As just mentioned, when ? is used on a Result, if it is Ok, the value inside Ok becomes the result of the expression and execution continues. That means the assignment step in the original code can be eliminated, and chained calls can be used directly.

9.3.5 `?` Can Only Be Used in Functions That Return `Result`

Take a look at an example:

use std::fs::File;
fn main() {
    let result = File::open("6657.txt")?;
}

Output:

error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `FromResidual`)
 --> src/main.rs:3:40
  |
2 | fn main() {
  | --------- this function should return `Result` or `Option` to accept `?`
3 |     let result = File::open("6657.txt")?;
  |                                        ^ cannot use the `?` operator in a function that returns `()`
  |
  = help: the trait `FromResidual<Result<Infallible, std::io::Error>>` is not implemented for `()`
help: consider adding return type
  |
2 ~ fn main() -> Result<(), Box<dyn std::error::Error>> {
3 |     let result = File::open("6657.txt")?;
4 +     Ok(())
  |

The error message says that the ? operator can only be used with return types such as Result or Option, which implement the Try trait, while main returns (), the unit type, which is equivalent to returning nothing.

But who says the return type of main must be the unit type? If you change the return type to Result, wouldn’t that solve it?

The code is as follows:

use std::error::Error;
use std::fs::File;

fn main() -> Result<(), Box<dyn Error>> {
    let result = File::open("6657.txt")?;

    Ok(())
}

Changing the return type to Result<(), Box<dyn Error>> means that if the program runs normally, it returns the Ok variant, which contains the unit type. If it does not run normally, it returns the Err variant, which contains Box<dyn Error> (Error here is std::error::Error). This is a trait object, which will be covered later; for now, you can simply think of it as any possible error type.
If the file is read successfully, ? returns the file data wrapped in Ok, assigns it to result, and then execution continues. Ok(()) is the last expression in main, so it returns the Ok variant and wraps the unit type.
If the file cannot be read successfully, ? returns Err(e) as the return value of main, and execution ends there.

[Rust Guide] 9.2. Result Enum and Recoverable Errors Pt. 1 - Match, Expect, and Unwrap Handling Errors

SomeB1oody — Sun, 26 Apr 2026 03:23:52 +0000

If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series.

9.2.1 The `Result` Enum

Usually, errors are not serious enough to stop the entire program. A function may fail or encounter an error for reasons that are often easy to explain and respond to. For example, a program may try to open a file that does not exist; in that case, you would usually consider creating the file rather than terminating the program immediately.

Rust provides the Result enum to handle these potentially failing cases. Its definition is:

enum Result<T, E> {
    Ok(T),
    Err(E),
}

It has two generic type parameters, T and E, and two variants, each associated with data. Ok is associated with T, and Err is associated with E. Generics will be discussed in Chapter 10. For now, just know that T is the type of the data returned by the Ok variant when the operation succeeds, and E is the type of the error returned by the Err variant when the operation fails.

Take a look at an example:

use std::fs::File;
fn main() {
    let f = File::open("6657.txt");
}

This code tries to open a file, but that file may not exist. In other words, the function may fail, so the return value of File::open is the Result enum. The first type parameter in this Result is std::fs::File, the file type returned on success, and the second is std::io::Error, the I/O error returned on failure.

9.2.2 Handling `Result` with `match`

Like the Option enum, Result and its variants are brought into scope by the prelude, so you do not need to import them explicitly when writing code. For example:

use std::fs::File;
fn main() {
    let f = File::open("6657.txt");
    let f = match f {
        Ok(file) => file,
        Err(e) => panic!("Error: {}", e),
    };
}

If the returned value is Ok, then the value associated with it is bound to file and returned to f. If the returned value is Err, then the error message is bound to e, printed by the panic! macro, and the program stops.

9.2.3 Matching Different Errors

Let’s improve the previous example. If the file is missing, create it. Only if creating the file also fails, or if some other error occurs besides “file not found” — such as not having permission to open it — should panic! be triggered.

use std::fs::File;
use std::io::ErrorKind;

fn main() {
    let f = File::open("6657.txt");
    let f = match f {
        Ok(file) => file,
        Err(e) => match e.kind() {
            ErrorKind::NotFound => match File::create("6657.txt") {
                Ok(fc) => fc,
                Err(e) => panic!("Problem creating file: {:?}", e),
            },
            other_error => panic!("Problem opening file: {:?}", other_error),
        },
    };
}

At the outermost level, if f is Ok, then the file is returned to f.
But the Err case is handled differently. The data carried by Err is of type std::io::Error. This struct has a .kind() method, which returns a value of type std::io::ErrorKind. That type is also an enum, also provided by the standard library, and its variants describe the different errors that io operations may cause.
ErrorKind has a variant called ErrorKind::NotFound, which means the file does not exist. In that case, the file should be created, which we will discuss below. Besides ErrorKind::NotFound, there may be other errors, such as lacking permission to read. Here, the other errors are bound to other_error, printed by panic!, and then the program stops.
To create a file, you can use File::create(), whose parameter is the file name. Creating a file can also fail, for example because of insufficient permissions, so the return value of File::create() is also a Result. Then another match expression is used to handle it. If it is Ok (creation succeeded), the value associated with Ok — that is, the contents of the newly created file (which are of course empty because the file is new) — are bound to fc and returned to f. If it is Err (creation failed), the error associated with Err is bound to e, printed by panic!, and the program stops.

match is indeed used quite often, but it is also fairly primitive. The nesting here greatly reduces readability, although compared with some other languages it may still be more readable. Chapter 13 will introduce a concept called a closure. Many methods on Result accept closures as parameters, and those methods are implemented using match, which can make the code much more concise. I am showing an example that uses closures here, but we will not cover it until Chapter 13.

use std::fs::File;
use std::io::ErrorKind;

fn main() {
    let greeting_file = File::open("6657.txt").unwrap_or_else(|error| {
        if error.kind() == ErrorKind::NotFound {
            File::create("6657.txt").unwrap_or_else(|error| {
                panic!("Problem creating the file: {error:?}");
            })
        } else {
            panic!("Problem opening the file: {error:?}");
        }
    });
}

9.2.4 The `unwrap` Method

match expressions are flexible and useful, but the code they produce is indeed a bit more complex. The Result enum itself also defines many helper methods for different tasks, and one of the most commonly used is unwrap.

If unwrap receives Ok, it returns the value attached to Ok; if it receives Err, unwrap calls the panic! macro. For example, here is a rewrite of the code from 9.2.2 using unwrap:

use std::fs::File;

fn main() {
    let f = File::open("6657.txt").unwrap();
}

unwrap is essentially a shortcut for a match expression. Its drawback is that the error message cannot be customized.

9.2.5 The `expect` Method

What if I want the convenience of unwrap but also want a custom error message? For that situation, Rust provides the expect method. If you remember, we already used this method in the number guessing game from Chapter 1.

Try rewriting the unwrap example with expect:

use std::fs::File;

fn main() {
    let f = File::open("6657.txt").expect("file not found");
}

DEV Community: SomeB1oody

[Rust Guide] 11.1. Writing and Running Tests

11.1.1 What Is Testing

11.1.2 Anatomy of a Test Function

11.1.3 Running Tests

11.1.4 Test Failures

[RustGuide] 10.8. Lifetime Annotations in Method Definitions and Static Lifetime

10.8.1 Lifetime Annotations in Method Definitions

10.8.2 The 'static Lifetime

10.8.3 Generic Type Parameters, Trait Bounds, and Lifetimes

[Rust Guide] 10.7. Input and Output Lifetimes and the 3 Rules

10.7.1 A Deeper Understanding of Lifetimes

1. The Way Lifetime Parameters Are Specified Depends on What the Function Does

2. When a Function Returns a Reference, the Lifetime Parameter of the Return Type Must Match One of the Input Lifetimes

10.7.2 Lifetime Annotations in Structs

10.7.3 Lifetime Elision

10.7.4 Input and Output Lifetimes

10.7.5 The Three Rules of Lifetime Elision

1. Successful Example

2. Failure Example

[Rust Guide] 10.6. Lifetime Syntax and Examples

10.6.1 Lifetime Annotation Syntax

10.6.2 Lifetime Annotation Examples

[Rust Guide] 10.5. Lifetime Definition and Significance, Borrow Checker, and Generic Lifetimes

10.5.1 What Is a Lifetime

10.5.2 Why Lifetimes Exist

10.5.3 The Borrow Checker

10.5.4 Generic Lifetimes in Functions

[Rust Guide] 10.4. Trait Pt.2 - Traits as Parameters and Return Types, Trait Bounds

10.4.1 Using Traits as Parameters

10.4.2 Using Traits as Return Types

Trait Bound Example

10.4.3 Conditionally Implementing Methods with Trait Bounds

[Rust Guide] 10.3. Trait Pt.1 - Trait Definitions, Bounds, and Implementation

10.3.1 What Is a Trait

10.3.2 Defining a Trait

10.3.3 Implementing a Trait for a Type

10.3.4 Trait Constraints

10.3.5 Default Implementations

[Rust Guide] 10.2. Generics

10.2.1 What Are Generics

10.2.2 Generics in Function Definitions

10.2.3 Generics in struct Definitions

10.2.4 Generics in enum Definitions

10.2.5 Generics in Method Definitions

10.2.6 Performance of Generic Code

[Rust Guide] 10.1. Extract Function to Eliminate Repeated Code

10.1.1 Repeated Code

10.1.2 Steps to Eliminate Repetition

[Rust Guide] 9.4. When Should You Use Panic!

9.4.1 General Principles

9.4.2 Scenarios Where panic! Is Appropriate

9.4.3 You Know Better Than the Compiler

9.4.5 Guiding Advice for Error Handling

9.4.6 Creating a Custom Type for Validation

[Rust Guide] 9.3. Result Enum and Recoverable Errors Pt. 2 - Error Propagation, Question Mark Operator, and Chained Calls

9.3.1 Propagating Errors

9.3.2 The ? Operator

9.3.3 ? and the from Function

9.3.4 Chained Calls

9.3.5 ? Can Only Be Used in Functions That Return Result

[Rust Guide] 9.2. Result Enum and Recoverable Errors Pt. 1 - Match, Expect, and Unwrap Handling Errors

9.2.1 The Result Enum

9.2.2 Handling Result with match

9.2.3 Matching Different Errors

9.2.4 The unwrap Method

9.2.5 The expect Method

10.8.2 The `'static` Lifetime

9.4.2 Scenarios Where `panic!` Is Appropriate

9.3.2 The `?` Operator

9.3.3 `?` and the `from` Function

9.3.5 `?` Can Only Be Used in Functions That Return `Result`

9.2.1 The `Result` Enum

9.2.2 Handling `Result` with `match`

9.2.4 The `unwrap` Method

9.2.5 The `expect` Method