dnrops
/
rfcs
mirror of https://github.com/rust-lang/rfcs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

No perma

This commit is contained in:
Michael Goulet 2024-07-02 14:33:59 -04:00
parent a514d3b4ac
commit d2446cb34e
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
text/3668-async-closure.md
View File

@ -10,7 +10,7 @@
# Summary
[summary]: #summary
This RFC adds an `async` bound modifier to the `Fn` family of trait bounds. The combination desugars to a set of perma-unstable `AsyncFn{,Mut,Once}` traits that parallel the current `Fn{,Mut,Once}` traits.
This RFC adds an `async` bound modifier to the `Fn` family of trait bounds. The combination desugars to a set of unstable `AsyncFn{,Mut,Once}` traits that parallel the current `Fn{,Mut,Once}` traits.
These traits give users the ability to express bounds for async callable types that are higher-ranked, and allow async closures to return futures which borrow from the closure's captures.
@ -146,7 +146,7 @@ When called, they return an anonymous future type corresponding to the (not-yet-
### `AsyncFn*`
This RFC introduces a family of `AsyncFn` traits. These traits are intended to remain perma-unstable to name or implement, just like the `Fn` traits. Nonetheless, we'll describe the details of these traits so as to explain the user-facing features enabled by them.
This RFC introduces a family of `AsyncFn` traits. These traits are intended to remain unstable to name or implement, just like the `Fn` traits. Nonetheless, we'll describe the details of these traits so as to explain the user-facing features enabled by them.
The definition of the traits is (modulo `rustc_` attributes, and the `"rust-call"` ABI):
@ -555,7 +555,7 @@ This shouldn't be too difficult to support, and we can unify these further by mo
There has been previous discussion of allowing `async` trait bounds on arbitrary traits, possibly based off a `?async` maybe-async genericity system.
This RFC neither requires this more general extension to the language to be implemented, nor does it necessarily preclude this being an eventual possibility, since `AsyncFn*` remains perma-unstable to implement.
This RFC neither requires this more general extension to the language to be implemented, nor does it necessarily preclude this being an eventual possibility, since `AsyncFn*` remains unstable to implement.
### Making `async Fn()` object-safe