如何使用更高等级的特征边界使返回的 impl Fn 更通用？

Question

I ran across Rust's higher-rank trait bounds recently and thought I could use them to make some functions in a parser I'm writing more generic. However, a modification I've made is giving me an error message that I can't make heads or tails of.

Here's what I've got right now that works:

use nom::bytes::complete::is_not;
use nom::character::complete::multispace0;
use nom::combinator::verify;
use nom::error::{
    ParseError,
    VerboseError,
};
use nom::sequence::terminated;
use nom::IResult;

fn one_token<'a, E>(input: &'a str) -> IResult<&str, &str, E>
where
    E: ParseError<&'a str>,
{
    terminated(is_not(" \t\r\n"), multispace0)(input)
}

fn str_token<'a, E>(expected_string: String) -> impl Fn(&'a str) -> IResult<&str, &str, E>
where
    E: ParseError<&'a str>,
{
    verify(one_token, move |actual_string| {
        actual_string == expected_string
    })
}

This compiles. However, my intuitions tell me that it's not necessarily great that the impl Fn I'm returning from str_token is bound by a lifetime parameter on str_token . I believe having it that way could unnecessarily restrict the usefulness of the impl Fn trait that gets returned. So I thought I could modify it to return an impl Fn that works for any lifetime 'b , regardless of what the lifetime of the factory function str_token_hrtb is:

fn str_token_hrtb<'a, E>(
    expected_string: String,
) -> impl for<'b> Fn(&'b str) -> IResult<&str, &str, E>
where
    E: ParseError<&'a str>,
{
    verify(one_token, move |actual_string| {
        actual_string == expected_string
    })
}

Now, the compiler is giving me these errors:

error[E0277]: expected a `std::ops::Fn<(&'b str,)>` closure, found `impl std::ops::Fn<(&str,)>`
  --> src/main.rs:29:6
   |
29 | ) -> impl for<'b> Fn(&'b str) -> IResult<&str, &str, E>
   |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected an `Fn<(&'b str,)>` closure, found `impl std::ops::Fn<(&str,)>`
   |
   = help: the trait `for<'b> std::ops::Fn<(&'b str,)>` is not implemented for `impl std::ops::Fn<(&str,)>`
   = note: the return type of a function must have a statically known size

error[E0271]: type mismatch resolving `for<'b> <impl std::ops::Fn<(&str,)> as std::ops::FnOnce<(&'b str,)>>::Output == std::result::Result<(&'b str, &'b str), nom::internal::Err<E>>`
  --> src/main.rs:29:6
   |
29 | ) -> impl for<'b> Fn(&'b str) -> IResult<&str, &str, E>
   |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected bound lifetime parameter 'b, found concrete lifetime
   |
   = note: the return type of a function must have a statically known size

I don't understand how to read this. Is it saying that the trait for<'b> std::ops::... is not implemented for the return value of verify ? If so, why not? And why wouldn't the same issue exist for str_token ? Also, I can't find any way to interpret the second type mismatch error message.

Can anyone give some insight on what I'm doing wrong here and what the compiler is trying to tell me?

Update :

I'm using the nom parsing library found here: https://github.com/Geal/nom/

Also, the code for the verify function is here: https://github.com/Geal/nom/blob/851706460a9311f7bbae8e9b7ee497c7188df0a3/src/combinator/mod.rs#L459

Another Update :

Decided to close this since I realized I may not have asked questions that were specific enough.

Answer 1

The error message is indeed less than ideal. That's because not all difficulties of the leak check step of handling the hrtb lifetimes have been ironed out yet. Niko has been working on it though.

If you turn off the leak check by pass +nightly -Zno-leak-check flag, you'll get a saner error message:

error: implementation of `std::ops::FnOnce` is not general enough
   --> src/main.rs:27:6
    |
27  |   ) -> impl for<'b> Fn(&'b str) -> IResult<&str, &str, E>
    |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `std::ops::FnOnce` is not general enough
    |
    = note: `impl std::ops::Fn<(&str,)>` must implement `std::ops::FnOnce<(&str,)>`
    = note: ...but `std::ops::FnOnce<(&'b str,)>` is actually implemented for the type `impl std::ops::Fn<(&str,)>`

Now, why does the compiler complain about FnOnce when you actually return Fn ? This is me speculating but it should be reasonable. FnOnce is a super-trait to Fn , rustc is saying the code doesn't even satisfy the super-trait there's no way it could satisfy the more restrained trait itself.

This finally makes sense now. Consider the fact that verify is defined as:

pub fn verify<I: Clone, O1, O2, E: ParseError<I>, F, G>(
    first: F, 
    second: G
) -> impl Fn(I) -> IResult<I, O1, E> where
    F: Fn(I) -> IResult<I, O1, E>,
    G: Fn(&O2) -> bool,
    O1: Borrow<O2>,
    O2: ?Sized,

By asking it to be:

impl for<'b> Fn(&'b str) -> IResult<&str, &str, E>
where
    E: ParseError<&'a str>,

you're asking forall<'b> 'b = 'a which simply isn't possible.

---

Understanding how lifetimes work in Rust is very helpful and almost mandatory. When writing your own code though, it is better to skip them whenever possible. The lifetime elide rules are there to help you do exactly that. One certainly doesn't reach for hrtb lifetimes voluntarily :D

For example, the more idiomatic way to write your one_token and str_token functions could be:

fn one_token(input: &str) -> IResult<&str, &str>
{
    let res = terminated(is_not(" \t\r\n"), multispace0)(input)?;

    Ok(res)
}

fn str_token(input: &str, expected_string: String) -> IResult<&str, &str>
{
    let res = verify(one_token, |actual_string| {
        actual_string == expected_string
    })(input)?;

    Ok(res)
}