How does "for<>" syntax differ from a regular lifetime bound?

Consider the following code:

trait Trait {}

fn foo(_b: Box>) {}
fn bar(_b: Box Trait>) {}

Both functions foo and bar seem to accept a Box>, although foo does it more concisely than bar. What is the difference between them?

Additionally, in what situations would I need for<> syntax like that above? I know the Rust standard library uses it internally (often related to closures), but why might my code need it?

for syntax is called Higher-Rank Trait Bound (HRTB), and it was indeed introduced mostly because of closures.

In short, the difference between foo and bar is that in foo() the lifetime for the internal usize reference is provided by the caller of the function, while in bar() the same lifetime is provided by the function itself. And this distinction is very important for the implementation of foo/bar.

However, in your particular example, when Trait has no methods that use the type parameter, this distinction is pointless, so let's imagine that Trait looks like this:

trait Trait {
    fn do_something(&self, value: T);
}

Remember, lifetime parameters are very similar to generic type parameters. When you use a generic function, you always specify all of its type parameters, providing concrete types, and the compiler monomorphizes the function. The same thing goes with lifetime parameters: when you call a function that has a lifetime parameter, you specify the lifetime, albeit implicitly:

// imaginary explicit syntax
// also assume that there is TraitImpl::new::() -> TraitImpl,
// and TraitImpl: Trait

'a: {
    foo::(Box::new(TraitImpl::new::()));
}

And now there is a restriction on what foo() can do with this value, that is, with which arguments it may call do_something(). For example, this won't compile:

fn foo(b: Box>) {
    let x: usize = 10;
    b.do_something(&x);
}

This won't compile because local variables have lifetimes that are strictly smaller than lifetimes specified by the lifetime parameters (I think it is clear why it is so), therefore you can't call b.do_something(&x) because it requires its argument to have lifetime 'a, which is strictly greater than that of x.

However, you can do this with bar:

fn bar(b: Box Trait>) {
    let x: usize = 10;
    b.do_something(&x);
}

This works because now bar can select the needed lifetime instead of the caller of bar.

This does matter when you use closures that accept references. For example, suppose you want to write a filter() method on Option:

impl Option {
    fn filter(self, f: F) -> Option where F: FnOnce(&T) -> bool {
        match self {
            Some(value) => if f(&value) { Some(value) } else { None }
            None => None
        }
    }
}

The closure here must accept a reference to T because otherwise, it would be impossible to return the value contained in the option (this is the same reasoning as with filter() on iterators).

But what lifetime should &T in FnOnce(&T) -> bool have? Remember, we don't specify lifetimes in function signatures only because there is lifetime elision in place; actually, the compiler inserts a lifetime parameter for each reference inside a function signature. There should be some lifetime associated with &T in FnOnce(&T) -> bool. So, the most "obvious" way to expand the signature above would be this:

fn filter(self, f: F) -> Option where F: FnOnce(&'a T) -> bool

However, this is not going to work. As in the example with Trait above, lifetime 'a is strictly longer than the lifetime of any local variable in this function, including value inside the match statement. Therefore, it is not possible to apply f to &value because of lifetime mismatch. The above function written with such signature won't compile.

On the other hand, if we expand the signature of filter() like this (and this is actually how lifetime elision for closures works in Rust now):

fn filter(self, f: F) -> Option where F: for FnOnce(&'a T) -> bool

then calling f with &value as an argument is perfectly valid: we can choose the lifetime now, so using the lifetime of a local variable is absolutely fine. And that's why HRTBs are important: you won't be able to express a lot of useful patterns without them.

You can read more about HRTBs in the Nomicon.

Stack Overflow Q#35592750, score: 183