Coroutine design notes #52
Conversation
| - Thus, the "generator" syntax proposed in [eRFC-2033][1] and currently | ||
| implemented behind the "generator" feature is actually a coroutine syntax for | ||
| the sake of these notes, *not a true generator*. | ||
| - Note also that "coroutines" here are really "semicoroutines" since they can |
There was a problem hiding this comment.
I wasn't aware of this distinction before and found this wiki entry helpful: https://en.wikipedia.org/wiki/Coroutine#Comparison_with_generators
There was a problem hiding this comment.
That is what @CAD97 linked to me as well to explain it! Although we make an additional distinction between generators and semicoroutines which Wikipedia does not seem to do.
|
I've pushed a new version of the notes which will hopefully address the feedback from @nikomatsakis and @cramertj. I left a lot of comments under those reviews but they have all been effectively merged into the notes, so I've marked the conversations as resolved. |
|
@samsartor thanks! will review. |
| - Exact inference rules may only be revealed by an attempt at implementation. | ||
| - If we forbid "borrowed data escaping into closure state", the inference | ||
| rules should be relatively simple: witnessing any borrow triggers | ||
| immovability. |
There was a problem hiding this comment.
This doesn't really work. For example:
|x: &Foo| {
let y = &x.field;
yield;
drop(y);
}
Here y is live across a yield but it does not require pinning.
There was a problem hiding this comment.
For that example to compile, we would need to allow borrowed inputs to escape into closure state. In that case, the inference is significantly more complex. But otherwise you'd get an error on the yield, something like:
3 | yield;
| ---- borrowed input `x` escapes into closure state
4 | drop(y);
| - borrow must enter state because it is used here
and the inference would never have to figure out that y is not borrowing from elsewhere in the witness.
I admit I'm not sure if the inference can be run after the escape check. But I'm assuming here that it can.
Obviously this error isn't the best. But since closures similarly forbid moving borrowed inputs into capture state, it is the easiest thing to do for the time being.
There was a problem hiding this comment.
@samsartor hmm, so, yes. I agree that if &Foo here means "each time the closure is invoked, it will be supplied a fresh reference", then I guess we really can't keep the reference live across the yield. There's definitely some subtlety here. Anyway, I'm going to merge this PR, and thank you again for the effort to create it!
I took a crack at a summary of the generalized coroutines design space! Please let me know if there are any questions I could do a better job of answering. I may be away from internet the next few days but I'll be around to answer them sooner than later.
Rendered