Rust - Exploring non-lexical lifetimes and how they aid in collection usage

In the realm of systems programming, performance and safety are key factors, and languages that offer fine-grained control over both are invaluable. Rust is such a language, uniquely offering a sophisticated type system that enforces strict ownership and borrowing rules. Part of these rules includes the novel concept of non-lexical lifetimes (NLL). In this article, we explore non-lexical lifetimes, how they differ from lexical lifetimes, and how they aid in collection usage in Rust.

Understanding Lifetimes

In Rust, lifetimes are a way of ensuring that references are valid as long as they are being used. Lexical lifetimes tied the lifetime of a variable strictly to the block of code (or scope) in which it was declared. However, this could be overly restrictive.

Consider the following scenario:

{
    let v;
    {
        let temp = String::from("Hello, world!");
        v = &temp;
    } // Here, temp goes out of scope, thus v would be dangling.
    println!("{}", v); // Error!
}

In the code above, under strict lexical lifetimes, v is considered to outlive temp, but temp goes out of scope, invalidating v. This leads to a compilation error because Rust's maturity prevents dangling references.

What are Non-Lexical Lifetimes?

With the introduction of non-lexical lifetimes in Rust 2018, the lifetimes of references can end before the scope does. This means that the compiler's borrow checker is more flexible and intelligent. Lifetimes are now based on usage rather than scope, reducing the boilerplate needed to satisfy the borrow checker.

Let's revisit the example with non-lexical lifetimes:

{
    let v;
    {
        let temp = String::from("Hello, world!");
        v = &temp;
        println!("{}", v);
    } // 'v' is no longer needed after its usage.
}

In this revised example, even though temp goes out of scope, v is only used while temp is still valid. The non-lexical lifetime tracks that v's usage concludes with the println! statement. Hence, the error is avoided.

Benefits in Collections

When it comes to working with collections in Rust, NLL offers enhanced flexibility. Consider the following collection processing:

fn process_vector(nums: &Vec) {
    for num in nums {
        if *num > 10 {
            println!("{} is greater than 10", num);
        }
    }
}

fn main() {
    let nums = vec![5, 11, 9, 15, 3];
    process_vector(&nums);
    // nums can be reused safely after borrow checker checks using NLL
    println!("Original vector remains: {:?}", nums);
}

In this example, the borrow of nums in process_vector doesn’t interfere with its reuse in main. Previously, any inadvertent compiler limitations could complicate such cases, but NLL minimizes such boilerplate.

Conclusion

Non-lexical lifetimes in Rust not only simplify lifetime management but also maximize the potential for borrowing, especially in scenarios involving complex data structures and collections. It allows the compiler to offer insightful precise lifetime checks based on reference usage, blending ergonomics with safety efficiently.

If you are diving into programming with Rust, harnessing non-lexical lifetimes is essential, especially when dealing with large codebases requiring heavy lifting by collections and avoiding cumbersome references.