::higher-order-closure

Allow function lifetime elision and explicit for<'a> annotations on closures.

Motivation / Rationale

See the RFC #3216: this crate is a Proof-of-Concept of the ideas laid out there[^1].

[^1]: with the exception of allowing elided lifetimes to have a meaning (chosen higher-order), which the RFC cannot do in order to be future-proof.

let f = |x| {
    let _: &i32 = x;
    x
};
{
    let scoped = 42;
    f(&scoped);
} // <- scoped dropped here.
f(&42);

error[E0597]: `scoped` does not live long enough
  --> src/lib.rs:10:7
   |
10 |     f(&scoped);
   |       ^^^^^^^ borrowed value does not live long enough
11 | } // <- scoped dropped here.
   | - `scoped` dropped here while still borrowed
12 | f(&42);
   | - borrow later used here

For more information about this error, try `rustc --explain E0597`.

impl Fn(&'inferred i32) -> &'inferred i32

{
    let scoped = 42;
    f(&scoped); // `'inferred` must "fit" into this borrow…
} // <- and thus can't span beyond this point.
f(&42) // And yet `'inferred` is used here as well => Error!

           // Rust sees this "hole" early enough in its compiler pass
           //                       to figure out that the closure signature
           // vv                    needs to be higher-order, **input-wise**
let f = |_x: &'_ i32| {
};
{
    let scoped = 42;
    f(&scoped);
}
f(&42);

impl Fn(&'inferred_and_thus_fixed i32)...

impl for<'any> Fn(&'any i32)...

let f = |x: &'_ i32| -> &'_ i32 {
    x // <- Error, does not live long enough.
};

error: lifetime may not live long enough
 --> src/lib.rs:5:5
  |
4 | let f = |x: &'_ i32| -> &'_ i32 {
  |             -           - let's call the lifetime of this reference `'2`
  |             |
  |             let's call the lifetime of this reference `'1`
5 |     x // <- Error, does not live long enough.
  |     ^ returning this value requires that `'1` must outlive `'2`

let f = /* for<'any> */ |x: &'any i32| -> &'inferred i32 {
    x // <- Error, does not live long enough (when `'any < 'inferred`)
};

Examples

This crate provides a higher_order_closure! macro, with which one can properly annotate the closure signatures so that they become higher-order, featuring universally quantified ("forall" quantification, for<…> in Rust) lifetimes:

#[macro_use]
extern crate higher_order_closure;

fn main ()
{
    let f = higher_order_closure! {
        for<'any> |x: &'any i32| -> &'any i32 {
            x
        }
    };
    {
        let local = 42;
        f(&local);
    }
    f(&42);
}

The lifetime elision rules of function signatures apply, which means the previous signature can even be simplified down to:

#[macro_use]
extern crate higher_order_closure;

fn main ()
{
    let f =
        higher_order_closure! {
            for<> |x: &'_ i32| -> &'_ i32 {
                x
            }
        }
    ;
}

or even:

#[macro_use]
extern crate higher_order_closure;

fn main ()
{
    let f =
        higher_order_closure! {
            |x: &'_ i32| -> &'_ i32 {
                x
            }
        }
    ;
}

• Because of these lifetime elision in function signatures semantics, it is highly advisable that the elided_lifetimes_in_paths be, at the very least, on warn when using this macro:

  //! At the root of the `src/{lib,main}.rs`.
  #![warn(elided_lifetimes_in_paths)]
  

Extra features

Macro shorthand

The main macro is re-exported as a hrtb! shorthand, to allow inlining closures with less rightward drift:

#[macro_use]
extern crate higher_order_closure;

fn main ()
{
    let f = {
        let y = 42;
        hrtb!(for<'any> move |x: &'any i32| -> &'any i32 {
            println!("{y}");
            x
        })
    };
}

Outer generic parameters

Given how the macro internally works[^2], generic parameters "in scope" won't, by default, be available in the closure signature (similar to consts and nested function or type definitions).

In order to make them available, higher_order_signature! accepts an initial optional #![with<simple generics…>] parameter (or even #![with<simple generics…> where clauses…] if the "simple shape" restrictions for the generic parameters are too restrictive).

<
    'a, 'b : 'a, ...
    T, U : ?Sized + 'a + ::core::fmt::Debug, V, ...
>

#[macro_use]
extern crate higher_order_closure;

use ::core::fmt::Display;

fn example<T : Display> (iter: impl IntoIterator<Item = (bool, T)>)
{
    let mb_display = higher_order_closure! {
        #![with<T>]
        |hide: bool, elem: &'_ T| -> &'_ dyn Display {
            if hide {
                &"<hidden>"
            } else {
                elem
            }
        }
    };
    for (hide, elem) in iter {
        println!("{}", mb_display(hide, &elem));
    }
}

fn main ()
{
    example([(false, 42), (true, 27), (false, 0)]);
}

Mixing higher-order lifetime parameters with inferred ones

Since inside higher_order_closure!, '_ has the semantics of lifetime elision for function signatures, it means that, by default, all the lifetime parameters appearing in such closure signatures will necessarily be higher-order.

In some more contrived or rare scenarios, this may be undesirable.

In that case, a nice way to work around that is by artificially introducing generic lifetime parameters as seen above, and using these newly introduced named lifetime parameters where the inferred lifetime would be desired.

#[macro_use]
extern crate higher_order_closure;

fn main ()
{
    let y = 42;
    let f = higher_order_closure! {
        #![with<'inferred>]
        for<'any> |x: &'any i32| -> (&'any i32, &'inferred i32) {
            (x, &y)
        }
    };
    let (&a, &b) = f(&27);
    assert_eq!(a + b, 42 + 27);
}

[^2]: it generates a "closure identity" helper function, with the desired higher-order signatures embedded as Fn bounds on its parameters, thus making it act as a "funnel" that only lets closure with the right signature pass through).