Are you sure this actually allows you to solve #6902? The stream is still going to need to be self-referential.

Well, I think it helps. My current plan for my downstream crate is to write a self-referential RecvOwned based on this by hand with unsafe - that seems less awkward to me than the previous workaround. Would that be something you would accept into tokio-stream as well (I guess if it was there, I could depend on tokio-stream in my downstream crate too)?

I can also think of two alternatives:

• Introduce NonSendReusableBoxFuture in tokio-util (the unsafe c'tor for ReusableBoxFuture seems much more risky to me, I tried something), use the same workaround as now but without copy-pasted code downstream
• Not sure whether it's possible, but I think it would be: Add Receiver::recv_owned(self) -> RecvOwned<T>, impl<T: Clone> Future for RecvOwned<T> { type Output = (T, Receiver<T>); } and avoid the whole business of self-referential futures

I don't love exposing future types because it makes the documentation worse. Right now, the function is documented as an async fn, but it's going to look like a synchronous function with this change. That's not to say we absolutely can't do it, and we have done so in the past with tokio::sync::futures::Notified. But I think it is unfortunate.

By the way, Notified is used for something similar here:

(The ci failure is fixed on master.)

Right, I agree about async fn looking better in the docs.

So, what would be your preferred solution here? I can go with whatever, including no changes to tokio at all (I have a working solution downstream already afterall, even though the reasoning around it being safe is a bit thin).

We can add this. Please expose the future in tokio::sync::futures and add a note to the docs about what the async fn signature would be, similar to how the Ext traits do so.

I have implemented the changes you asked for.

I haven't had any focus time for finishing the hand-written self-referential future based on this (what motivated me to write this PR). One thing I have already found is that the T: Clone bound of the Recv type (rather than only its Future impl) might get in the way a little bit, but that could be relaxed later – it's currently required due to Coop, but I'm pretty sure could be removed by doing the Coop logic with a freestanding fn rather than wrapping RecvInner in Coop.

Given this uncertainty, I wouldn't mind if merging this PR was delayed until I finish the downstream work that needs this, though it could lead to bitrot. However you want to deal with this is fine by me.

Inlining the coop logic into RecvInner::poll is fine with me.