Allow using `for<'a>` syntax when declaring closures by Aaron1011 · Pull R...

Copy link

Member

let closure = for<'a> |val: &'a u8| println!("Val: {:?}", val);
closure(&25);

Diggsey commented 10 days ago

Would this allow the following code to be uncommented:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=465408ec84cee8e2736c0ac6cc46bade

This has been a long time limitation of async functions, so it would be great if it allowed that restriction to be lifted, but the RFC isn't clear whether this is expected to work, since it relies on the returned future also being generic over the lifetime.

Aaron1011 commented 10 days ago

@Diggsey: I think that issue would be unaffected by this RFC, since there isn't a way to explicitly specify the desugared return type (let along lifetime) of an async move closure.

Diggsey commented 10 days ago

@Aaron1011 I'm not sure I follow? You can replace example in my code with this definition:

fn example<'a>(arg: &'a i32) -> impl Future + 'a {
    async move {
        *arg == 42
    }
}

And it still compiles - there was no need to specify a "return type" for async move, it just gets inferred.

Aaron1011 commented 10 days ago

@Diggsey I think the root of that issue is the inability to write a higher-order async move closure:

fn main() {
    let _ = |arg: &i32| async move {
        arg;
    };
}

produces:

error: lifetime may not live long enough
 --> src/main.rs:2:25
  |
2 |       let _ = |arg: &i32| async move {
  |  ___________________-___-_^
  | |                   |   |
  | |                   |   return type of closure `impl Future<Output = [async output]>` contains a lifetime `'2`
  | |                   let's call the lifetime of this reference `'1`
3 | |         arg;
4 | |     };
  | |_____^ returning this value requires that `'1` must outlive `'2`

Diggsey commented 10 days ago

Isn't my last example just as "higher-order" as the closure example?

Aaron1011 commented 10 days ago

Do you mean my closure example, or something from the RFC itself?

I think the problem you're running into has to do with the way that we desugar an async move closure. When you write async fn bar<'a>(val: &'a) {}, then the desugared impl Future return type ends up 'capturing' the 'a lifetime from the parameter. However, that doesn't seem to be happening in the closure example, leading to the error.

Diggsey commented 10 days ago •

I mean:

fn example<'a>(arg: &'a i32) -> impl Future + 'a {
    async move {
        *arg == 42
    }
}

(works)

|arg: &i32| async move {
    *arg == 42
};

(does not work, but might with for<'a>)

When you write async fn bar<'a>(val: &'a) {}, then the desugared impl Future return type ends up 'capturing' the 'a lifetime from the parameter.

But my example doesn't use async fn

Aaron1011 commented 10 days ago

But my example doesn't use async fn

I mean that the code should pretty much equivalent to the async fn I mentioned, so I think it might just be a bug in how the desugaring is being performed.

Aaron1011 commented 10 days ago

@Diggsey On further investigation, I believe that this RFC is actually related to your issue. Currently, there's no easy way of getting a closure of the form for<'a> |input: &'a T| -> &'a T| (with a matching higher-ranked lifetime in the input and output). For example, the following code:

fn main() {
    let _ = |val: &i32| -> &i32 { val };
}

produces the following error:

error: lifetime may not live long enough
 --> src/main.rs:2:35
  |
2 |     let _ = |val: &i32| -> &i32 { val };
  |                   -        -      ^^^ returning this value requires that `'1` must outlive `'2`
  |                   |        |
  |                   |        let's call the lifetime of this reference `'2`
  |                   let's call the lifetime of this reference `'1`

In order to get the desired signature, you need to pass the closure to a function expecting an FnOnce with the desired signature. With this RFC, you can directly specify the desired lifetime with for<'a>.

However, this unfortunately isn't enough to fix your case - you can't write impl Future + 'a in the return type. You would need the ability to write impl Trait in a closure return type, or the compiler would need to infer the '+a for you. However, using the FnOnce trick, you can get it to compile by introducing an additional trait:

trait MyTrait {}

impl<T> MyTrait for T {}

fn constrain<T, F: FnOnce(&T) -> Box<dyn MyTrait + '_>>(val: F) -> F { val }

fn main() {
    constrain(|arg: &i32| {
        Box::new(async move {
            *arg == 42;
        })
    });
}

WaffleLapkin commented 10 days ago

Could # Future possibilities also mention bounds? Like for<'a, 'b: 'a> |...| {...} and similar stuff? Or is it way out of scope since for<'a, 'b: 'a> fn(&'a u8, &'b u8) type isn't allowed either?

Aaron1011 commented 10 days ago

@WaffleLapkin Since we currently don't have higher-ranked bounds for function pointers, I would personally consider that out of scope.

cynecx commented 8 days ago

@Diggsey, @Aaron1011 Is this rust-lang/rust#70263 related to the issue you are talking about?