How does for syntax differ from a regular lifetime bound?

by

for<> syntax is called higher-ranked 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 this particular case, when Trait has no methods which use the type parameter, this distinction is pointless, so let’s imagine that Trait looks like this:

trait Trait<T> {
    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. Same thing goes with lifetime parameters: when you call a function which have a lifetime parameter, you specify the lifetime, albeit implicitly:

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

'a: {
    foo::<'a>(Box::new(TraitImpl::new::<&'a usize>()));
}

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<'a>(b: Box<Trait<&'a usize>>) {
    let x: usize = 10;
    b.do_something(&x);
}

This won’t compile because local variables have lifetimes which 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<for<'a> Trait<&'a usize>>) {
    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 which accept references. For example, suppose you want to write a filter() method on Option<T>:

impl<T> Option<T> {
    fn filter<F>(self, f: F) -> Option<T> 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<'a, F>(self, f: F) -> Option<T> 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<F>(self, f: F) -> Option<T> where F: for<'a> 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 also read another explanation of HRTBs in Nomicon.

More Related Contents:

  1. How do I synchronously return a value calculated in an asynchronous Future in stable Rust?
  2. Why does refactoring by extracting a method trigger a borrow checker error?
  3. What is this question mark operator about?
  4. How to test for equality between trait objects?
  5. How do I borrow a reference to what is inside an Option?
  6. What is lifetime elision in very simple terms?
  7. error [E0716]: temporary value dropped while borrowed (rust)
  8. Can I get a trait object of a multi-trait instance without using a generic type?
  9. Why does this read input before printing?
  10. How to create a String directly?
  11. How to create an in-memory object that can be used as a Reader, Writer, or Seek in Rust?
  12. What’s the Rust idiom to define a field pointing to a C opaque pointer?
  13. Trait implementation for both a trait object and for direct implementors of the trait
  14. Can’t borrow mutably within two different closures in the same scope
  15. How can I implement Rust’s Copy trait?
  16. How to iterate over and filter an array?
  17. How to use a struct’s member as its own key when inserting the struct into a map without duplicating it?
  18. How to fix lifetime error when function returns a serde Deserialize type?
  19. Is there another option to share an Arc in multiple closures besides cloning it before each closure?
  20. Understanding Traits and Object Safety
  21. How to implement a custom ‘fmt::Debug’ trait?
  22. How do I pass a closure through raw pointers as an argument to a C function?
  23. Is there a way to use existing structs as enum variants?
  24. How do I use a crate from another crate without explicitly defining a new dependency in my project?
  25. How do I specify that a struct field must implement a trait?
  26. What does Rust’s unary || (parallel pipe) mean?
  27. How to create and write to memory mapped files?
  28. Downcast traits inside Rc for AST manipulation
  29. How to check in Rust if architecture is 32 or 64 bit?
  30. Is there any way to restrict a generic type to one of several types?

Leave a Comment