rust
/
rfcs
mirror of https://github.com/rust-lang/rfcs
1
0
Fork 0
Code Issues Releases Wiki Activity

Adjust for `Generator -> Coroutine` rename 

For many years, we had a trait in nightly Rust called `Generator`.
We've now renamed this to `Coroutine`, but this RFC still referred to
it as `Generator`.  Let's use the new name and make a note of the old
one.
This commit is contained in:
Travis Cross 2024-03-14 23:09:31 +00:00
parent b836635a4a
commit 6478947eb4
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
text/0000-gen-fn.md
View File

@ -191,11 +191,11 @@ on iterators over `Result`s.
## Implementation ## Implementation
This feature is mostly implemented via existing generators, though there are some special cases. This feature is mostly implemented via existing coroutines, though there are some special cases.
### `gen` blocks ### `gen` blocks
`gen` blocks are the same as an unstable generator... `gen` blocks are the same as an unstable coroutine...
* ...without arguments, * ...without arguments,
* ...with an additional check forbidding holding borrows across `yield` points, * ...with an additional check forbidding holding borrows across `yield` points,
@ -207,7 +207,7 @@ This feature is mostly implemented via existing generators, though there are som
It's another language feature for something that can already be written entirely in user code. It's another language feature for something that can already be written entirely in user code.
In contrast to `Generator`, `gen` blocks that produce `Iterator`s cannot hold references across `yield` points. In contrast to `Coroutine`s (currently unstable), `gen` blocks that produce iterators cannot hold references across `yield` points.
See [`from_generator`][] which has an `Unpin` bound on the generator it takes to produce an `Iterator`. See [`from_generator`][] which has an `Unpin` bound on the generator it takes to produce an `Iterator`.
The `gen` keyword causes some fallout in the community, mostly around the `rand` crate, which has `gen` methods on its traits. The `gen` keyword causes some fallout in the community, mostly around the `rand` crate, which has `gen` methods on its traits.
@ -220,7 +220,7 @@ The `gen` keyword causes some fallout in the community, mostly around the `rand`
We could use `iter` as the keyword. We could use `iter` as the keyword.
I prefer `iter` because I connect generators with a more powerful scheme than plain `Iterator`s. I prefer `iter` because I connect generators with a more powerful scheme than plain `Iterator`s.
The `Generator` trait can do everything that `iter` blocks and `async` blocks can do and more. The unstable `Coroutine` trait (which was previously called `Generator`) can do everything that `iter` blocks and `async` blocks can do and more.
I believe connecting the `Iterator` trait with `iter` blocks is the right choice, I believe connecting the `Iterator` trait with `iter` blocks is the right choice,
but that would require us to carve out many exceptions for this keyword as `iter` is used for module names and method names everywhere (including libstd/libcore). but that would require us to carve out many exceptions for this keyword as `iter` is used for module names and method names everywhere (including libstd/libcore).
It may not be much worse than `gen` (see also [the unresolved questions][unresolved-questions]). It may not be much worse than `gen` (see also [the unresolved questions][unresolved-questions]).
@ -234,7 +234,7 @@ Some of these new methods would need to be very generic.
While it's not an `Iterator` example, [`array::try_map`][] is something that has very complex diagnostics that are hard to improve, even if it's nice once it works. While it's not an `Iterator` example, [`array::try_map`][] is something that has very complex diagnostics that are hard to improve, even if it's nice once it works.
Users can use crates like [`genawaiter`](https://crates.io/crates/genawaiter) or [`propane`](https://crates.io/crates/propane) instead. Users can use crates like [`genawaiter`](https://crates.io/crates/genawaiter) or [`propane`](https://crates.io/crates/propane) instead.
`genawaiter` works on stable and provides `gen!` macro blocks that behave like `gen` blocks, but don't have compiler support for nice diagnostics or language support for the `?` operator. The `propane` crate uses the `Generator` trait from nightly and works mostly `genawaiter` works on stable and provides `gen!` macro blocks that behave like `gen` blocks, but don't have compiler support for nice diagnostics or language support for the `?` operator. The `propane` crate uses the `Coroutine` trait from nightly and works mostly
like `gen` would. like `gen` would.
The standard library includes [`std::iter::from_fn`][], which can be used in The standard library includes [`std::iter::from_fn`][], which can be used in
@ -736,18 +736,18 @@ The macro would expand to a `for` loop + `yield`.
yield_all!(iter) yield_all!(iter)
``` ```
## Complete `Generator` support ## Complete `Coroutine` support
We already have a `Generator` trait on nightly that is more powerful than the `Iterator` We already have a `Coroutine` trait on nightly (previously called `Generator`) that is more powerful than the `Iterator`
API could possibly be: API could possibly be:
1. It uses `Pin<&mut Self>`, allowing self-references in the generator across yield points. 1. It uses `Pin<&mut Self>`, allowing self-references across yield points.
2. It has arguments (`yield` returns the arguments passed to it in the subsequent invocations). 2. It has arguments (`yield` returns the arguments passed to it in the subsequent invocations).
Similar to the ideas around `async` closures, Similar to the ideas around `async` closures,
I think we could argue for `Generators` to be `gen` closures while `gen` blocks are a simpler concept that has no arguments and only captures variables. I think we could argue for coroutines to be `gen` closures while `gen` blocks are a simpler concept that has no arguments and only captures variables.
Either way, support for full `Generator`s should be discussed and implemented separately, Either way, support for full coroutines should be discussed and implemented separately,
as there are many more open questions around them beyond a simpler way to write `Iterator`s. as there are many more open questions around them beyond a simpler way to write `Iterator`s.
## `async` interactions ## `async` interactions