Skip to content

Commit 662654b

Browse files
Slightly elaborate drawback with non-nameable RTN
1 parent 2e35b78 commit 662654b

File tree

1 file changed

+21
-1
lines changed

1 file changed

+21
-1
lines changed

text/3668-async-closure.md

Lines changed: 21 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -633,7 +633,27 @@ We can similarly implement a lint to detect cases where users write these two-pa
633633

634634
It's not possible to directly name the future returned by calling some generic `T: async Fn()`. This means that it's not possible, for example, to convert `futures-rs`'s [`StreamExt::then` combinator](https://docs.rs/futures/0.3.30/futures/stream/trait.StreamExt.html#method.then), since the output future is referenced in the definition of [`Then`](https://docs.rs/futures-util/0.3.30/src/futures_util/stream/stream/then.rs.html#19) returned by the combinator.
635635

636-
Fixing this is a follow-up goal that we're interested in pursuing in the near future.
636+
For example, consider a `Then` combinator that allows mapping a stream under a future:
637+
638+
```rust
639+
pub struct Then<St, F, Fut, U>
640+
where
641+
St: Stream,
642+
F: async FnMut(St::Item) -> Fut::Output,
643+
Fut: Future,
644+
{
645+
stream: St,
646+
fun: F,
647+
future: Option</* how do we name this future type? */>,
648+
649+
}
650+
```
651+
652+
The first problem here is that the RTN [RFC 3654](https://github.com/rust-lang/rfcs/pull/3654) says that RTN is only allowed in *trait bound* positions, so we can't use it to name the returned future in type position, like in this struct field, without further design work.
653+
654+
Secondly, even if we could name the `CallRefFuture` type directly, we still need a lifetime to plug into the GAT. Conceptually, the future lives for the transient period of processing a single element in the stream, which isn't representable with a lifetime argument. We would need some sort of `'unsafe` or unsafe binder type.
655+
656+
Fixing this is a follow-up goal that we're interested in pursuing in the near future. Design work regarding naming the future types in struct position can be done additively on top of what is exposed in this RFC, and ties into the larger question of how to use RTN in struct fields and other non-inference type positions.
637657

638658
# Prior art
639659
[prior-art]: #prior-art

0 commit comments

Comments
 (0)