Skip to content

Async fn implicit capture requirement is confusing #103470

Closed
@jkelleyrtp

Description

@jkelleyrtp

I've never really seen this documented anywhere, but as a result of

#60388 which solved #60203,

there is now a weird discrepancy between regular fns and async fns when that makes it confusing to "upgrade" an fn to an async fn.

In particular, with implicit lifetimes, many users would not need to know about the '_ lifetime being necessary.

In the simplest case, take this struct

struct Context<'a> { inner: &'a Inner }

with a regular fn, we can pass it into the arguments with complete elision

fn run(cx: Context) {}

However, if we want to upgrade the the function to be async:

async fn run(cx: Context) {}

we are greeted with an error:

error[E0726]: implicit elided lifetime not allowed here
  --> example.rs:71:20
   |
71 | async fn run(cx: Context) {}
   |                    ^^^ expected lifetime parameter
   |
   = note: assuming a `'static` lifetime...
help: indicate the anonymous lifetime
   |
71 | async fn run(cx: Context <'_>) {}
   |                     ++++

This is not an obvious error, especially given that for all other functions, NLL kicks in and this is never a requirement.

I'd personally prefer to not require the elided lifetime on async fns when the regular fn does not need it either.

In 2019, this decision was made as a way of "future proofing" async and to fix a specific bug. However, I think for the sake of consistency, we should loosen the restrictions and allow NLL to work the same in async fns as it does in regular fns.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions