Supports for async closures #823
Assignees
Comments
|
There is no need to add You can simply add a single built-in implementation for each impl<F, A, Fut, O> AsyncFn<A> for F where F: Fn<A, Output = Fut>, Fut: Future<Output = O> {}
impl<F, A, Fut, O> AsyncFnMut<A> for F where F: FnMut<A, Output = Fut>, Fut: Future<Output = O> {}
impl<F, A, Fut, O> AsyncFnOnce<A> for F where F: FnOnce<A, Output = Fut>, Fut: Future<Output = O> {} |
|
Or if that leads to ambiguity with the blanket impls, then the impls could be restricted specifically to closures, fn pointers, and fn def self types. |
|
For the record, this is what I said in rust-lang/rust-analyzer#18591 (comment) |
|
Thanks! I'll try in that way |
|
@rustbot claim |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
c.c rust-lang/rust-analyzer#19196
I'm afraid that implementing this on chalk and using on rust-analyzer would make currently ongoing rust-analyzer's trait solver migration more difficult but we need this to improve user experiences for Rust's shiny new async closures.
LangItemandWellKnownTraitforAsyncFn*TyKindfor async closures. rustc categorizes them toCoroutineClosurebut rust-analyzer categorizes them toClosure. I'd like to follow the rustc way for consistency but this might hinder currently ongoing trait solver migration in rust-analyzer a bitAsyncFn*implementation supports for async closures and functions that returns futureI'm planning to start working on this tomorrow but if this is not welcomed due to next gen solver migrations or other issues, I'll gladly look for alternatives 😄
The text was updated successfully, but these errors were encountered: