Skip to content

Commit 757977a

Browse files
Last tweaks
1 parent d630123 commit 757977a

File tree

1 file changed

+3
-8
lines changed

1 file changed

+3
-8
lines changed

posts/inside-rust/2024-08-09-async-closures-call-for-testing.md

Lines changed: 3 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -20,21 +20,16 @@ let x = || { async {} };
2020

2121
This had a fundamental limitation that it was impossible to express a closure that returns a future that borrows captured state.
2222

23-
Somewhat relatedly, on the callee side, when users want to take an async closure as an argument, they must express that as a bound of two different generic types, or use boxing:
23+
Somewhat relatedly, on the callee side, when users want to take an async closure as an argument, they typically express that as a bound of two different generic types:
2424

2525
```rust
2626
fn async_callback<F, Fut>(callback: F)
2727
where
2828
F: FnOnce() -> Fut,
2929
Fut: Future<Output = String>;
30-
31-
// Or:
32-
fn async_callback_boxed<F, Fut>(callback: F)
33-
where
34-
F: FnOnce() -> Pin<Box<dyn Future<Output = String>>>;
3530
```
3631

37-
This led to an additional limitation, that it's impossible to express higher-ranked async fn bounds using this without boxing (since a higher-ranked trait bound on `F` cannot lead to a higher-ranked type for `Fut`), leading to unnecessary allocations:
32+
This also led to an additional limitation that it's impossible to express higher-ranked async fn bounds using this without boxing (since a higher-ranked trait bound on `F` cannot lead to a higher-ranked type for `Fut`), leading to unnecessary allocations:
3833

3934
```rust
4035
fn async_callback<F, Fut>(callback: F)
@@ -146,7 +141,7 @@ We expect to improve async closure signature inference as we move forward.
146141

147142
Some libraries take their callbacks as function *pointers* (`fn()`) rather than generics. Async closures don't currently implement the same coercion from closure to `fn() -> ...`. Some libraries may mitigate this problem by adapting their API to take generic `impl Fn()` instead of `fn()` pointers as an argument.
148143

149-
We don't expect to implement this coercion unless there's a particularly good reason to support it, since this can usually be handled manually by the caller by using an inner function item, or by using an `Fn` bound instead: for example:
144+
We don't expect to implement this coercion unless there's a particularly good reason to support it, since this can usually be handled manually by the caller by using an inner function item, or by using an `Fn` bound instead, for example:
150145

151146
```rust
152147
fn needs_fn_pointer<T: Future<Output = ()>>(callback: fn() -> T) { todo!() }

0 commit comments

Comments
 (0)