- >,
) {
while let Some(mut iter) = iters.pop_front() {
while let Some(next) = iter.next().await {
iters.push_back(iter);
println!("{next:?}");
iter = iters
.pop_front()
.expect("we just push_back'ed an iter, there has to be one!");
}
}
}
```
I am pretty sure that no solution will be able to caller-site cache the second function.
### `Box` it as a default
> [@](#):
>
> As an example of where this might matter, it might be that you are writing some sensitive systems code where allocation is something you always do with great care. It doesn’t mean the code is no-std, it may have access to an allocator, but you still would like to know exactly where you will be doing allocations. Today, you can audit the code by hand, scanning for “obvious” allocation points like `Box::new` or `vec![]`. Under this proposal, while it would still be _possible_, the presence of an allocation in the code is much less obvious. The allocation is “injected” as part of the vtable construction process. To figure out that this will happen, you have to know Rust’s rules quite well, and you also have to know the signature of the callee (because in this case, the vtable is built as part of an implicit coercion). In short, scanning for allocation went from being relatively obvious to requiring a PhD in Rustology. Hmm.
I would like to give the [rust for linux project](https://github.com/Rust-for-Linux/linux) as an example. Kernel developers would _absolutely_ not like implicit allocations. `async` is already being used in some experimental drivers.
### General thoughts
I think it would be better to select the type of returning at the call site. So the ABI for dynamic dispatch `async` functions should include a strategy selection stub/multiple functions should be generated with the different strategies.
Most often the caller will have a better idea of the constraints than the callee. It will also prevent the following scenario: What if a dependency suddenly changed to use `Boxing` instead of `InlineAsyncIterator`? Implementation details should not leak into my crate!
I would _really_ like to see an attempt at a solution with the placement by return RFC that @Jules-Bertholet alreay mentioned.
---
### Author:  [@kornel](https://internals.rust-lang.org/u/kornel)
#### Post date: [September 18, 2022, 9:06pm UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/4 "2022-09-18T21:06:19Z")
I do value the transparency and control aspects. I'd be fine with an explicit `Boxing::new()` adapter.
---
### Author:  [@PoignardAzur](https://internals.rust-lang.org/u/PoignardAzur)
#### Post date: [September 18, 2022, 10:25pm UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/5 "2022-09-18T22:25:59Z")
> [@Jules-Bertholet](#):
>
> What would be the tradeoffs of using the [placement by return](https://github.com/rust-lang/rfcs/pull/2884) RFC for this?
It feels like every single time Niko writes one of those posts, someone will mention placement return, and every single time Niko ignores it.
We even had a pretty big discussion on the subject on zulip a few months back, where various trade-offs were mentioned.
It's pretty disappointing none of that was mentioned in Niko's post. At that point it feels like arguing in circles.
---
### Author:  [@withoutboats](https://internals.rust-lang.org/u/withoutboats)
#### Post date: [September 18, 2022, 10:29pm UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/6 "2022-09-18T22:29:34Z")
(NOT A CONTRIBUTION)
In my opinion, the boxing adapter will just be yet another annoying, frustrating, and undiscoverable thing that users in the async ecosystem will have to deal with. This will continue to harm async Rust's reputation unnecessarily.
Pragmatically, the anathema on allocation has never been sensible in my opinion. Rust will happily let you memcpy megabytes with no transparency, but heaven forbid you increment an Rc's refcount silently. These decisions were arbitrary and don't represent a philosophy that actually benefits users, from my perspective. As async is actually used in production, any time you're awaiting you're probably performing network IO of some kind and the allocation is literally orders of magnitude cheaper.
However, I think the fact that this hasn't been decided, nearly 3 years after shipping the MVP, does a lot more harm to async Rust's reputation than requiring some boxing adapter will do. The Rust project (and especially the language team) have an attitude toward discussions and the consensus process that in my opinion is toxic and doing a lot of harm to Rust the product (and I include my past conduct on await syntax in this assessment). I will be happy to see any solution to async trait methods shipped in stable Rust.
---
### Author:  [@Jules-Bertholet](https://internals.rust-lang.org/u/Jules-Bertholet)
#### Post date: [September 18, 2022, 10:44pm UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/7 "2022-09-18T22:44:52Z")
> [@withoutboats](#):
>
> Rust will happily let you memcpy megabytes with no transparency
The placement by return RFC would make such dangerous memcpys less common and easier to avoid, in addition to allowing total control over heap allocation and unsized returns.
---
### Author:  [@Jules-Bertholet](https://internals.rust-lang.org/u/Jules-Bertholet)
#### Post date: [September 18, 2022, 11:16pm UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/8 "2022-09-18T23:16:53Z")
To elaborate, here is an example use case that is **not `no_std` specific** (can happen in regular application code) and that only placement-by-return can address:
```rust
trait AsyncFoo {
async fn do_lots_of_work_with_a_big_future(&self);
async fn very_simple_function_small_future(&self);
}
async fn do_the_work(foo: &dyn AsyncFoo) {
// We want to box this future because it's really big.
// We don't care if this is slow
Box::new_with(|| foo.do_lots_of_work_with_a_big_future()).await;
// Tight loop! Business critical!
// Every millisecond counts!
loop {
// Heap allocation would be too slow here
StackBox::new_with(|| foo.very_simple_function_small_future()).await;
}
}
```
---
### Author:  [@Skepfyr](https://internals.rust-lang.org/u/Skepfyr)
#### Post date: [September 18, 2022, 11:42pm UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/9 "2022-09-18T23:42:49Z")
Edit: Reading the placement-by-return RFC I think this is the same suggestion as the above comments.
The way I would naturally expect this to work is like this:
```rust
async fn use_dyn(iter: &dyn AsyncIterator) {
Box::new(iter.next()).await
}
```
Essentially the alloca method but just require boxing (or some inderection) at await points. I think that's the placement new method others above have mentioned.
Specifically I think it requires:
- The AsyncIterator trait object to contain the vtable for the returned future type, so that the caller knows its size, alignment, and poll method.
- Something like unsized locals and placement new.
This allows the ability to do most (all?) of the patterns described, and to me is simple, transparent, easy to make perrormant, easy to produce understandable errors, and very similar to Boxing in terms of productivity. It also has the benefit of not using any particularly weird features, I'm worried a bit that Boxing would be quite magic and people would want to write similar but subtly different versions but not be able to.
---
### Author:  [@Jules-Bertholet](https://internals.rust-lang.org/u/Jules-Bertholet)
#### Post date: [September 19, 2022, 12:45am UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/10 "2022-09-19T00:45:58Z")
> [@Skepfyr](#):
>
> `Box::new(iter.next()).await`
Placement by return is basically this, with one complication. Function arguments are passed on the stack before a function is called, but you can't put unsized values on an `async fn`'s stack. So instead, you pass in a closure to `Box::new_with`. `new_with` calls the closure and provides a _place_ on the heap for the closure to _return_ the unsized value (hence "placement by return"). The result looks like:
```rust
Box::new_with(|| iter.next()).await
```
---
### Author:  [@JoJoJet](https://internals.rust-lang.org/u/JoJoJet)
#### Post date: [September 19, 2022, 1:52am UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/11 "2022-09-19T01:52:56Z")
> [@Jules-Bertholet](#):
>
> ```rust
> Box::new_with(|| iter.next()).await
>
> ```
I feel this could be made more elegant by having `Box::new` lazily evaluate its argument. Something like
```rust
impl Box {
pub fn new(lazy val: T) -> Self { ... }
}
```
Then it really could just be
```rust
Box::new(iter.next()).await
```
---
### Author:  [@Jules-Bertholet](https://internals.rust-lang.org/u/Jules-Bertholet)
#### Post date: [September 19, 2022, 2:03am UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/12 "2022-09-19T02:03:50Z")
> [@Jules-Bertholet](#):
>
> you can't put unsized values on an `async fn`'s stack
Actually, I suppose you could, they just can't be held across an `await`. Hmmm...
---
### Author:  [@y86-dev](https://internals.rust-lang.org/u/y86-dev)
#### Post date: [September 19, 2022, 9:38am UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/13 "2022-09-19T09:38:39Z")
> [@PoignardAzur](#):
>
> We even had a pretty big discussion on the subject on zulip a few months back, where various trade-offs were mentioned.
I have only been able to find [this](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/return.20position.20impl.20Trait.20in.20dyn.20Trait/near/276384740), was that the whole discussion?
I would like to understand why placement by return cannot be used here.
> What follows is, I think, an exhaustive list of the various ways one might handle the situation.
I think it should be listed as an option.
---
### Author:  [@PoignardAzur](https://internals.rust-lang.org/u/PoignardAzur)
#### Post date: [September 19, 2022, 9:41am UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/14 "2022-09-19T09:41:53Z")
> [@y86-dev](#):
>
> I have only been able to find [this](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/return.20position.20impl.20Trait.20in.20dyn.20Trait/near/276384740), was that the whole discussion?
Yeah, it was.
(I was going to go dig for it, thanks for saving me the time)
---
### Author:  [@Skepfyr](https://internals.rust-lang.org/u/Skepfyr)
#### Post date: [September 19, 2022, 9:59am UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/15 "2022-09-19T09:59:20Z")
Turns out this kinda already works (after enabling quite a lot of features), the only thing that's really missing is for dyn async traits to return `dyn Future`s. It would be quite cool for trait objects to return trait objects instead of associated types where possible, making a bunch of traits object safe.
> **[Rust Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=4c47a3fc34e5dbe90af2a69b33b9c1ef)**
>
> A browser interface to the Rust compiler to experiment with the language
---
### Author:  [@y86-dev](https://internals.rust-lang.org/u/y86-dev)
#### Post date: [September 19, 2022, 10:34am UTC](https://internals.rust-lang.org/t/blog-series-dyn-async-in-traits-continues/17403/16 "2022-09-19T10:34:59Z")
So I found [this](https://hackmd.io/@nikomatsakis/S1xxjkZGc#Unsized-returns-aka-caller-decides) document created in the zulip discussion posted above. It states:
> async contexts, and generators in general, do not support unsized allocation on the stack (also known as alloca). This is because their stack values that exist across await points are pre-allocated. Futures being awaited always exist across await points, so this approach would not support stack allocation.
As @Jules-Bertholet already pointed out:
> [@Jules-Bertholet](#):
>
> Actually, I suppose you could, they just can't be held across an `await`. Hmmm...
This is because the generator has two stacks, one normal function stack and one generator stack that is preserved across `yield`/`await`. The function stack is renewed every time. I think that the limitation then would just be "before the next `yield`/`await`, figure out where to store this". There would need to be some support for storing `dyn Trait` in fixed-size fields, example:
```rust
async fn print_all(iter: &mut dyn AsyncIterator- ) {
while let Some(next: dyn Future