1. 20

  2. 3

    Would someone more familiar with rust sort of explain what’s going on here?

    My understanding is they’re rewriting the borrow checker to somehow be smarter about inferring ownership. He kept throwing around “NLL” but I couldn’t readily find what that stands for.

    1. 9

      NLL is Non-Lexical Lifetimes. Lifetimes in Rust so far are determined essentially by the same rules as variable scope; a program is not allowed to have references to a variable after that variable goes out of scope. This is easy to implement and easy to reason about, but not terribly flexible.

      NLL does more powerful analysis based off the actual data flow in the program, which basically relaxes the rules somewhat. I believe the canonical introduction to the concept is here: http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/

      1. 7

        Everything icefox says is true, here is a (runnable) simple example that hints at why we want it so badly:

        let mut v = vec![0]; // Create a Vector (growable array) containing a single element `0`.
        let ref_v = &v[0]; // Take a reference to that element
        if opaque() {
            println!("{}", ref_v); // Do something with that reference
        else {
            v.push(2); // Mutate the vector

        without NLL, i.e. with lexical lifetimes, the compiler doesn’t know that we won’t use ref_v inside the else block. As such it has to reject the code (otherwise ref_v might become a dangling pointer if the vector reallocates itself). With NLL we know that we never use ref_v again if we enter the else block, so we can accept this code.

        This pattern comes up all the time in real life, it’s basically always possible to work around it, but often it makes the code less elegant.