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

[MajorBreakfast]

About “output of”:

• I didn’t notice it in the case of typeof because I see it everyday in JavaScript, but the two words concatenated together look a bit weird.
• I’d suggest to make it lowercase because it itself is not a type, it just returns a type
• It could be a compiler built-in: output_of!()

My preferred syntax is still fn_name<..>::Output where Output refers to the associated type of the FnOnce trait. It doesn’t get any shorter.

One issue is that with a true typeof , you’d need turbofish: <typeof foo::<T>>::Output

You said that a while back. I’ve also never questioned why turbofish has the extra :: in there. Is it to avoid parsing ambiguities? Why do you think that that the turbofish operator should be used there?

[rpjohnst]

My preferred syntax is still fn_name<..>::Output where Output refers to the associated type of the FnOnce trait. It doesn’t get any shorter.

This would be committing to “a function’s name is also the name of its type,” which seems okay to me but also kind of a big deal? For one, that’s currently not allowed- you need the <T as Trait>::Output syntax, so enabling that would be new. Second, error messages currently print out a function’s type as fn(A, B) -> C {foo}, which seems important because it’s close enough to the function pointer type syntax that you could guess that the coercion exists.

(Also, there’s something about the current grammar not allowing turbofish in the middle of a path, but I’m not totally clear on when that applies.)

[comex]

You said that a while back. I’ve also never questioned why turbofish has the extra :: in there. Is it to avoid parsing ambiguities? Why do you think that that the turbofish operator should be used there?

Yes, it’s to avoid parsing ambiguities between <> used for generics and as the less-than/greater-than operators. It shows up wherever generics are used in expression context.

[comex]

On top of what @withoutboats describes, typeof tends to accumulate a lot of hacks. The core problem is you have to be able to come up with a value for the type you want to talk about, which is not always easy or possible, which then leads to things like C++'s declval .

Fair point, though… A big part of the need for declval in C++ was the lack of another way to ask “what type does this function return, given these argument types?”. There’s now std::result_of for that, but its implementation just uses declval. In Rust, on the other hand, you can theoretically just project to a Fn* trait’s Output associated type.

I say theoretically, because currently there’s a pretty silly obstacle to doing so. You can write

<MyFuncTy as FnOnce<(u32,)>>::Output

but that depends on unstable (and ugly) syntax. You can’t write

<MyFuncTy as FnOnce(u32)>::Output

because writing FnOnce(u32) implies a return type of (). Nor does using an underscore work:

<MyFuncTy as FnOnce(u32) -> _>::Output

I wonder if that could be made to work backwards-compatibly. That is, when the return type is _, instead of desugaring to FnOnce<(Args,), Output=_>, just desugar to FnOnce<(Args,)>.

The 'input lifetime is a brilliant idea! I think it’s even possible to add this in a 100% non-breaking way to Rust 2015. It can be defined by default and an explicitly defined lifetime called “input” simply shadows it (plus there should be a warning).

How about 'in? That’s already reserved because in is a keyword, and it’s more succinct.

[MajorBreakfast]

How about 'in ?

Attractive because it’s so short. I like it.

'params would also work nicely. However, the shorter the better, I suppose.

[MajorBreakfast]

Here’s a code example: I hope I didn’t get anything wrong. I was obviously only able to check the currrently working stuff

Common: Setup code shared between all following code examples

struct MyStruct<T> { x: T }
trait MyTrait<T> { type Item; fn foo(&self) -> &T; }
impl<T> MyTrait<T> for MyStruct<T> { type Item = Box<T>; fn foo(&self) -> &T { &self.x } }

let my_struct = MyStruct { x: 42 };

Expression context: Referring to method without <.. as Trait>

let _ = <MyStruct<i32> as MyTrait<i32>>::foo(&my_struct); // Current
let _ = MyStruct<i32>::foo(&my_struct); // Proposed
let _ = my_struct.foo(); // Current: This already works for method calls

Type context: Referring to associated type without <.. as Trait>

let _ : <MyStruct<i32> as MyTrait<i32>>::Item = Box::new(123); // Current
let _ : MyStruct<i32>::Item = Box::new(123); // Proposed

Bad future

• We need <.. as Trait> to refer to a method or an associated type
• We need <typeof foo> to refer to the type of a function

let _ : <<typeof <MyStruct<i32> as MyTrait<i32>>::foo> as FnOnce(&MyStruct<i32>) -> &i32>::Output = my_struct.foo();

Looks like C++ template programming ^^’

(See the scrollbar? Did you use it? )

output_of

let _ : output_of!(<MyStruct<i32> as MyTrait<i32>>::foo) = my_struct.foo();
let _ : output_of!(MyStruct<i32>::foo) = my_struct.foo(); // Without `<.. as Trait>`

Question: I wonder: What’s actually inside of output_of?

• It’s not actually an expression because it’s incomplete
• Type also makes no sense because typeof and outputof are introduced to avoid making functions types

Edit: Answer by @withoutboats

Good future

let _ : MyStruct<i32>::foo::Output = my_struct.foo();

We can read from left to right, yay!

[MajorBreakfast]

Yes, it’s to avoid parsing ambiguities between <> used for generics and as the less-than/greater-than operators. It shows up wherever generics are used in expression context.

Perfect. Then we should be fine in <typeof ..> or with Type::Output without turbofish because those are type contexts. Edit: I can’t decide what context is in inside <typeof ..> (I even said so in my previous post ^^’)

BTW I see that nested comparisons without parenthesis lead to an error. Maybe turbofish can be removed in the future without making the parser type aware? Who knows… Doesn’t matter for this discussion, though.

[CAD97]

Question: I wonder: What’s actually inside of output_of ?

• It’s not actually an expression because it’s incomplete
• Type also makes no sense because typeof and outputof are introduced to avoid making functions types

If functions are addressable as a type to query their <... as FnOnce>::Output, it would make sense to take a $:ty match.

However, this isn’t possible even with $($:tt)+ matches and unboxed_closures in user code:

error[E0575]: expected associated type, found method `MyTrait::foo`
  --> src/main.rs:13:23
   |
13 |     let _ : OutputOf!(<MyStruct<u32> as MyTrait<u32>>::foo)
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not a associated type

I’d like to note though that if we get <..> elision for generic arguments, OutputOf! can almost be implemented purely in library code:

macro_rules! OutputOf {
    ($($path:tt)+) => (<$($path)+ as FnOnce<..>>::Output);
}

Of course, if it becomes a compiler built-in macro to work around the unstable nature of the Fn* traits, then you could handwave a bit and say it takes a “path to a method” (which seems the compiler already knows about, to say that it isn’t an associated type).

---

Sorry, I didn’t see that you mentioned type directly. I’m too tired to reorganize this on my phone but the last paragraph is still directly relevant, it just needs the earlier bits for context.

I’ve also mixed up what works and what doesn’t a bit at this point so I may have missed something obvious, that’s why I’m leaning on actually putting things on play.

[Centril]

Assorted notes:

• I like 'in. Short and sweet as @MajorBreakfast said.

• We can improve upon <MyFuncTy as FnOnce<(u32,)>>::Output with a type alias like so:

  type Out<F, Args> = <F as FnOnce<Args>>::Output;
  
  Out<MyFuncTy, (u32,)>
  

  Using Out will ensure that the bound FnOnce<Args> is satisfied but it is not checked on the type alias itself right now.

• I second @withoutboats’s view on -> async T. Some more notes…

• async is an effect, just like unsafe, const (anti-effect / restriction) and try (assuming we have try…) are. Whatever we do, I think it is important that there be consistency between effects so that we don’t have (more) of an unprincipled mess. That is, if we write:

  fn foo() -> async i32 { .. }
  

  Then you should also write:

  fn foo() -> unsafe i32 { .. }
  fn foo() -> const i32 { .. }
  ...
  

  However, the ship has sailed on unsafe fn.

• One could imagine the following syntaxes (which I’m not suggesting…)

  fn foo() -> async(T, Bound) { .. }
  fn foo() -> async(T) { .. }
  

• Some criticisms of async(Bound) fn foo() -> i32:

  1. Bound is too front and center, especially if Bound is long.
  2. It appears before quantification of type variables and where, adding yet another syntax for bounds.

• With the introduction of 'in, maybe consider the following instead:

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

  or even:

  trait Async<T, trait B = 'static> = Future<Output = T> + B;
                 // ^--- This depends on quantification over bounds.
                 // Can't do that right now; but it can be added later
                 // backwards compatibly. EDIT: Actually, probably not..
  
  async fn foo(x: &Type1, y: &Type2) -> impl Async<Type3, 'in> { .. }
  
  async fn foo(x: u32, y: u32) -> impl Async<u32> { .. }
  
  async fn foo(x: u32, y: u32) -> impl Async<u32, Send> { .. }
  

  This seems to work better in conjunction with proposed schemes for try fn:

  try fn foo() -> Result<T, E> { .. }  // return type is mentioned as above!
  

[MajorBreakfast]

Out<MyFuncTy, (u32,)>

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.

async fn foo(x: &Type1, y: &Type2) -> impl 'in + Async<i32> { … }

^^’ 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.

[Centril]

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

So the idea was to shorten Future<Output = T> to Async<T> which becomes somewhat more ergonomic if you write it often. However, this trait alias can be added in user code, so you can make it as short as you wish if you repeat it often. If it turns out to be a common problem after years of experimentation, the alias can be added to the standard library.

Upsides of specifying the outer return type after all:

One additional benefit of -> T instead of -> impl Future<Output = T> is that it mixes well with ideas about async-polymorphism, i.e: if you could write:

?async fn foo() -> T { .. }

Then you can let the caller decide whether the return type is a future, or just a normal T. This could enable us to write a library that is polymorphic over async-ness and let the client application decide. Writing -> impl Future<Output = T> out explicitly takes that option away.

Of course, writing:

?async(Send) fn foo() -> T { .. }

would make no sense.

[MajorBreakfast]

If it turns out to be a common problem after years of experimentation, the alias can be added to the standard library.

Sure. However, we’re talking about saving 8 characters, so I guess not ^^’ Edit: If you want something short: How about a (user defined) fut!(T) macro? Will the proposed type trait aliases even be able to convert between a generic param and an associated type?

One additional benefit of -> T instead of -> impl Future<Output = T> is that it mixes well with ideas about async-polymorphism

Hmm. Reminds me of the mut-polymorphism I’ve read about discussed somewhere long ago that was ultimately discarded. As a result we now have for example Iter and IterMut. Both are nice ideas, but IMO too ambitious to be practical. Some downsides:

• It means that we need to specify whether we want to use the sync or the async version in some cases. Type inference will sometimes not be able to tell
• my_fn::Output is impossible. At least not if there’s no way to specify whether we want the sync or the async version.
• A lot of async code requires a different implementation than the sync code. So the ?async syntax will often be not applicable
• You mention ?async(Send). I agree. It’s weird. Same goes for the awaits of course. They would also not affect the sync case
• Traits are currently the only source of polymorphism that Rust has that I’m aware of (not counting macros). There’s beauty to that. Edit: Corrected by @Centril

My conclusion: I don’t think that it makes sense to add async polymorphism to the language.

[Centril]

Sure. However, we’re talking about saving 8 characters, so I guess not ^^’

Don’t underestimate the effect of small paper-cuts repeated many times. After all, there’s a reason it is fn and impl instead of function and implementation.

How about a (user defined) fut!(T) macro?

Haha, sure why not Time will tell?

Will the proposed type trait aliases even be able to convert between a generic param and an associated type?

Yes. Why would they not be able to? This is no different than the following, which is legal today:

trait Bar { type Assoc; }
type Foo<T> = Box<dyn Bar<Assoc = T>>;
type Baz = Foo<u32>;

The only difference is that the kind of Foo would be type -> trait (trait = type -> constraint) instead of type -> type.

Reminds me of the mut-polymorphism I’ve read about discussed somewhere long ago that was ultimately discarded.

This is effect polymorphism, which is different than mut polymorphism. See Do be do be do, Conor McBride et. al for a discussion on such things.

It means that we need to specify whether we want to use the sync or the async version in some cases. Type inference will sometimes not be able to tell

Presumably there would be some light weight syntax to say when you want what.

You could also do:

?async fn foo() -> u32 { .. }

async fn bar() -> u32 { foo() } // we decide that `foo` is async here.
fn baz() -> u32 { foo() } // we decide that `foo` is sync here.

my_fn::Output is impossible. At least not if there’s no way to specify whether we want the sync or the async version.

True; for ?async saying such a thing is impossible. However, once you use an ?async function inside an async function, then it is possible as seen above.

• You mention ?async(Send) . I agree. It’s weird. Same goes for the await s of course. They would also not affect the sync case

It is not just weird, it is meaningless. However, await!ing inside ?async with await!(expr) when it has been made into sync could perhaps be considered the same as { expr } (provided that expr came from another ?async fn).

• Traits are currently the only source of polymorphism that Rust has that I’m aware of (not counting macros). There’s beauty to that.

That’s not true. Rust has two forms of polymorphism, a) parametric polymorphism, for example fn id<A>(x: A) -> A { x } is polymorphic but involves no traits. b) ad-hoc polymorphism in the form of traits. The point of polymorphism is reuse (by specifying reasoning about data and algorithms generally without extraneous details). Consider const fn for example – unless you want to repeat logic once for const fn and once for fn, then some way to avoid that is necessary. Effect polymorphism is one answer. However, I leave the question of whether I believe in (a)sync polymorphism for Rust unresolved for now.

PS: Maybe we should continue further discussion on async-polymorphism (if you are interested that is…) in a separate thread so it doesn’t clutter up this one…

[lordan]

How about a (user defined) fut!(T) macro?

On behalf of all German speakers, please not that exact name (very NSFW)!

trailing -> async T

@Centril, @withoutboats, I agree with (almost) all the points made for the current async fn syntax. However, I think I need to clarify:

The trailing -> async T syntax was intended for function declarations, and on the definition side the “initialization pattern” case - i.e., where a “normal” (immediately executing) function returns an async block. AFAICT there is currently no syntactic support for this case, other than the proposed 'in/'input lifetime above (?). Having to switch from a declaration that says async fn foo() -> T; to an implementation of fn foo() -> impl Future<Output=T> + 'in { ... } and mentally consider them equivalent is not very ergonomic IMHO.

That said, there is an additional issue with -> async T: it’s not clear which parameter lifetimes should be included in the resulting type (not every input parameter must necessarily be used in the future).

FWIW, for the “standard” async fn definition I added fn foo() as async T { ... } as a possible alternative, mainly for symmetry, and to emphasize that the function body itself is transformed. Symmetric especially if we allowed specifying the return type of async blocks:

    init_stream();
    return async i32 { stream.next_value() };

(Technically unnecessary, but documenting, and could catch errors when the code is changed)

Regarding “typeof”

How about adding a <fn foo> syntax in some form or another to get the type of a function, rather than a new keyword:

MyStruct<T>::<fn foo<A, B>>::Output     // or thereabouts

[MajorBreakfast]

On behalf of all German speakers, please not that exact name (very NSFW)!

Hmm. I’m from Germany. I’ve never heard of the word. I had to look it up. Maybe we don’t use that word in Bavaria? ^^’

Having to switch from a declaration that says async fn foo() -> T; to an implementation of fn foo() -> impl Future<Output=T> + 'in { ... }

It’d look like this:

// Note: Outer return type approach!

// Declaration
fn foo(a: &i32, b: &i32) -> impl Future<Output=T> + 'in;

// Definition
async fn foo(a: &i32, b: &i32) -> impl Future<Output=T> + 'in { ... }

Or with a bound:

// Note: Outer return type approach!

// Declaration
fn foo(a: &i32, b: &i32) -> impl Future<Output=T> + Send + 'in;

// Definition
async fn foo(a: &i32, b: &i32) -> impl Future<Output=T> + Send + 'in { ... }

Solving the bound problem is what this thread is about after all. It’s IMO a good solution that fits in well with the rest of Rust.

[lordan]

// Definition
async fn foo() -> impl Future<Output=T> + 'in { ... }

o_O? Wouldn’t that do the async fn definition magic and again wrap the result, giving something like:

fn foo() -> impl Future<Output = impl Future<Output = T> + 'in> + 'in { ... }

Edit: (fixed quote)

[MajorBreakfast]

@lordan The RFC just chose to use the inner return type approach. The code above uses the outer return type approach (no wrapping). See my comment above about the advantages. IMO the RFC did not properly consider the downsides this thread has discovered with the inner return type approach. Therefore a reevaluation is required.

Abstract types are also no problem with the outer return type approach:

// Note: Outer return type approach!

abstract type Foo<'a>: Future<Output=i32> + 'a;

async fn foo(a: &i32, b: &i32) -> Foo<'in> { ... }

[lordan]

Thanks for the clarification, I missed that part!

Agreed, that does look cleaner to me as well. Less magic is always a plus.

[DDOtten]

If we write the Future itself I don’t see the need for async functions anymore. const and unsafe both have effects other users should care about when they see the api in the documentation. However

async fn foo(a: &i32, b: &i32) -> impl Future<Output = i32> + Send + 'in {
    //...
}
// would be equivalent to
fn foo(a: &i32, b: &i32) -> impl Future<Output = i32> + Send + 'in {
    async {
        //...
    }
}
// or if you dont want another level of indentation.
fn foo(a: &i32, b: &i32) -> impl Future<Output = i32> + Send + 'in { async {
    //...
}}

This way using async would stay an implementation detail. Another benefit of this approach would be the simularity to more complex functions like

fn foo(a: &i32, b: &i32) -> impl Future<Output = i32> + Send + 'in {
    // do some work first
    let future = async {
        //...
    }
    // and maybe even use some combinators.
    future
}

This approach has no need for additional syntax like async(Send). Maybe async fn can be added as syntactic sugar later but I don’t think it should be included in the initial proposal.

[MajorBreakfast]

Yes, but:

• It’s the most frequent use case. The async fn syntax isn’t strictly necessary, but it improves ergonomics. Its frequent use justifies its existence.

• async would not be the first thing that rustdoc chooses not to show: E.g

  // Today: mut
  pub fn foo(mut a: i32) { ... } // Code
  pub fn foo(a: i32) // Rustdoc
  
  // async (outer return type approach)
  pub async fn foo (a: &str, b: &str) -> imp Future<Output=i32> + 'in { ... } // Code
  pub fn foo (a: &str, b: &str) -> imp Future<Output=i32> + 'in // Rustdoc
  

• }} is very ugly

• Other programming languages have async functions as well.