Pre-Pre-RFC: async methods & bounding async fns

I prefer <MyFuncTy as FnOnce(u32,)>::Output because that's more direct. However this syntax should only be required in cases where it is necessary to resolve ambiguity, i.e. next to never: For the type of a function there'd be never any ambiguity (because functions can't implement arbitrary traits) and for most other types ambiguities are really rare (we hardly ever need to use this syntax to call methods after all). So the short version MyFuncTy::Output (or MyType::MyAssocType in general) should almost always work.

^^' complicated (too indirect for my taste). But the idea is good. It's essentially specifying the outer return type:

async fn foo(x: &Type1, y: &Type2) -> impl Future<Output=i32> + 'in { .. }

The RFC mentions 3 reasons against specifying the outer return type:

  • Lifetimes: Can be considered solved by 'in. Also, if the inner to outer type conversion like the RFC defines it isn't considered too drastic, a simple shortcut that makes + 'in optional for async functions is certainly also possible!
  • Polymorphic return not required: The rationale is that it's always an impl Future, so there's no need to specify it. While this is somewhat true, we've now discovered serious downsides to this which the RFC does not mention. See next section.
  • Documentation: With point 1 addressed I consider it a rather weak argument

Upsides to specifying the outer return type after all:

  • Bounds can be specified as usual. No weird async(Send) fn required
  • Seamless integration with abstract types
  • It makes async functions more similar to regular functions
  • async then only affects the body, not the signature
    • async (like mut in fn foo(mut a: i32)) can simply be omitted in Rustdoc.
    • This makes the signatures of functions using the initialization pattern and functions defined via async fn identical.

It's a bit late now that the RFC is merged. But nobody had the 'in lifetime idea when we discussed the RFC. Going with the outer return type has advantages and we should talk about it again now that we have these insights.

3 Likes