Precise generator capturing and how it interacts with a future possibility

[SkiFire13]

@chrefr

However, Rc specifically is not problematic; it is true that it cannot be moved between threads, but only if there is no clones left in the original threads. Async blocks will never leave a clone in the original thread, so they can safely hold a Rc across .await points.

This is true only if you ignore thread locals. Otherwise the async block could both store a clone of the Rc in a thread local of the original thread and keep another instance internally to use later on.

@chrefr

But semantically, a value created in the async block can originate from a value captured by the async block, and the compiler can't tell. So, this leads us to the following understanding:

If any value captured by the async block is !Send, the async block must be !SendNoEscape, even if this value is dropped before the first .await point.

The problematic situation seems to be when:

• the async block captures a !Send + SendNoEscape value;
• it uses such value to create another !Send + SendNoEscape value;
• it drops/consumed the original captured value;
• all of this happens before the first await;
• the new value is then held across a await.

Is this correct? If it is then I don't see where's the breaking change. Even with precise capturing this Future will be !Send because the new value is still !Send and is held across an await point.

Your rule also seems too restricting, as it should probably apply only when a !Send + SendNoEscape value is held across a .await. With this it's clear that it should never happen to situations where a Future is currently Send. Edit: nevermind this is wrong

In general I would expect any SendNoEscape proposal to allow strictly more code than the equivalent with only Send bounds. As such there should be no examples that compile with Send bounds (even after precise capturing) but don't with SendNoEscape.