Tracking Issue for gen blocks and functions
#117078
Assignees
Labels
B-RFC-approved
Blocker: Approved by a merged RFC but not yet implemented.
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
F-gen_blocks
`gen {}` expressions that produce `Iterator`s
Comments
oli-obk
added
the
C-tracking-issue
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 29, 2023
Implement `gen` blocks in the 2024 edition Coroutines tracking issue rust-lang#43122 `gen` block tracking issue rust-lang#117078 This PR implements `gen` blocks that implement `Iterator`. Most of the logic with `async` blocks is shared, and thus I renamed various types that were referring to `async` specifically. An example usage of `gen` blocks is ```rust fn foo() -> impl Iterator<Item = i32> { gen { yield 42; for i in 5..18 { if i.is_even() { continue } yield i * 2; } } } ``` The limitations (to be resolved) of the implementation are listed in the tracking issue
This comment was marked as resolved.
This comment was marked as resolved.
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Nov 2, 2023
Implement `gen` blocks in the 2024 edition Coroutines tracking issue rust-lang/rust#43122 `gen` block tracking issue rust-lang/rust#117078 This PR implements `gen` blocks that implement `Iterator`. Most of the logic with `async` blocks is shared, and thus I renamed various types that were referring to `async` specifically. An example usage of `gen` blocks is ```rust fn foo() -> impl Iterator<Item = i32> { gen { yield 42; for i in 5..18 { if i.is_even() { continue } yield i * 2; } } } ``` The limitations (to be resolved) of the implementation are listed in the tracking issue
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this issue
Nov 2, 2023
Implement `gen` blocks in the 2024 edition Coroutines tracking issue rust-lang/rust#43122 `gen` block tracking issue rust-lang/rust#117078 This PR implements `gen` blocks that implement `Iterator`. Most of the logic with `async` blocks is shared, and thus I renamed various types that were referring to `async` specifically. An example usage of `gen` blocks is ```rust fn foo() -> impl Iterator<Item = i32> { gen { yield 42; for i in 5..18 { if i.is_even() { continue } yield i * 2; } } } ``` The limitations (to be resolved) of the implementation are listed in the tracking issue
This comment was marked as resolved.
This comment was marked as resolved.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Dec 8, 2023
Introduce support for `async gen` blocks I'm delighted to demonstrate that `async gen` block are not very difficult to support. They're simply coroutines that yield `Poll<Option<T>>` and return `()`. **This PR is WIP and in draft mode for now** -- I'm mostly putting it up to show folks that it's possible. This PR needs a lang-team experiment associated with it or possible an RFC, since I don't think it falls under the jurisdiction of the `gen` RFC that was recently authored by oli (rust-lang/rfcs#3513, rust-lang#117078). ### Technical note on the pre-generator-transform yield type: The reason that the underlying coroutines yield `Poll<Option<T>>` and not `Poll<T>` (which would make more sense, IMO, for the pre-transformed coroutine), is because the `TransformVisitor` that is used to turn coroutines into built-in state machine functions would have to destructure and reconstruct the latter into the former, which requires at least inserting a new basic block (for a `switchInt` terminator, to match on the `Poll` discriminant). This does mean that the desugaring (at the `rustc_ast_lowering` level) of `async gen` blocks is a bit more involved. However, since we already need to intercept both `.await` and `yield` operators, I don't consider it much of a technical burden. r? `@ghost`
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Dec 8, 2023
Introduce support for `async gen` blocks I'm delighted to demonstrate that `async gen` block are not very difficult to support. They're simply coroutines that yield `Poll<Option<T>>` and return `()`. **This PR is WIP and in draft mode for now** -- I'm mostly putting it up to show folks that it's possible. This PR needs a lang-team experiment associated with it or possible an RFC, since I don't think it falls under the jurisdiction of the `gen` RFC that was recently authored by oli (rust-lang/rfcs#3513, rust-lang#117078). ### Technical note on the pre-generator-transform yield type: The reason that the underlying coroutines yield `Poll<Option<T>>` and not `Poll<T>` (which would make more sense, IMO, for the pre-transformed coroutine), is because the `TransformVisitor` that is used to turn coroutines into built-in state machine functions would have to destructure and reconstruct the latter into the former, which requires at least inserting a new basic block (for a `switchInt` terminator, to match on the `Poll` discriminant). This does mean that the desugaring (at the `rustc_ast_lowering` level) of `async gen` blocks is a bit more involved. However, since we already need to intercept both `.await` and `yield` operators, I don't consider it much of a technical burden. r? `@ghost`
ytmimi
pushed a commit
to ytmimi/rustfmt
that referenced
this issue
Dec 12, 2023
Introduce support for `async gen` blocks I'm delighted to demonstrate that `async gen` block are not very difficult to support. They're simply coroutines that yield `Poll<Option<T>>` and return `()`. **This PR is WIP and in draft mode for now** -- I'm mostly putting it up to show folks that it's possible. This PR needs a lang-team experiment associated with it or possible an RFC, since I don't think it falls under the jurisdiction of the `gen` RFC that was recently authored by oli (rust-lang/rfcs#3513, rust-lang/rust#117078). ### Technical note on the pre-generator-transform yield type: The reason that the underlying coroutines yield `Poll<Option<T>>` and not `Poll<T>` (which would make more sense, IMO, for the pre-transformed coroutine), is because the `TransformVisitor` that is used to turn coroutines into built-in state machine functions would have to destructure and reconstruct the latter into the former, which requires at least inserting a new basic block (for a `switchInt` terminator, to match on the `Poll` discriminant). This does mean that the desugaring (at the `rustc_ast_lowering` level) of `async gen` blocks is a bit more involved. However, since we already need to intercept both `.await` and `yield` operators, I don't consider it much of a technical burden. r? `@ghost`
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this issue
Dec 16, 2023
Introduce support for `async gen` blocks I'm delighted to demonstrate that `async gen` block are not very difficult to support. They're simply coroutines that yield `Poll<Option<T>>` and return `()`. **This PR is WIP and in draft mode for now** -- I'm mostly putting it up to show folks that it's possible. This PR needs a lang-team experiment associated with it or possible an RFC, since I don't think it falls under the jurisdiction of the `gen` RFC that was recently authored by oli (rust-lang/rfcs#3513, rust-lang/rust#117078). ### Technical note on the pre-generator-transform yield type: The reason that the underlying coroutines yield `Poll<Option<T>>` and not `Poll<T>` (which would make more sense, IMO, for the pre-transformed coroutine), is because the `TransformVisitor` that is used to turn coroutines into built-in state machine functions would have to destructure and reconstruct the latter into the former, which requires at least inserting a new basic block (for a `switchInt` terminator, to match on the `Poll` discriminant). This does mean that the desugaring (at the `rustc_ast_lowering` level) of `async gen` blocks is a bit more involved. However, since we already need to intercept both `.await` and `yield` operators, I don't consider it much of a technical burden. r? `@ghost`
|
Tracking issues have a tendency to become unmanageable. Please open a dedicated new issue and label it with |
traviscross
added
the
B-RFC-approved
7 tasks
|
We're now tracking the aspects of this related to the release of Rust 2024 separately here: |
adpaco-aws
pushed a commit
to adpaco-aws/rust
that referenced
this issue
Apr 18, 2024
…iter, r=compiler-errors Implement `FusedIterator` for `gen` block cc rust-lang#117078
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a tracking issue for the RFC "#3513" (rust-lang/rfcs#3513).
The feature gate for the issue is
#![feature(gen_blocks)].About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
genblocks in the 2024 edition #116447)Iterators fused (so they keep returningNoneafter the firstNoneinstead of panicking (which is what they do now))FusedIterator- ImplementFusedIteratorforgenblock #122829Unresolved Questions
Iteratordirectly or, e.g.,IntoIteratororIntoGenerator.genblocks prior to stabilization.gen.genas a full keyword or as a contextual one.size_hint.DoubleEndedIteratororExactSizeIterator.k#genmay or may not be workable.Related issues
Implementation history
genblocks in the 2024 edition #116447gen fn#118457Rng::gento avoid conflicting with a keyword in Rust 2024 rust-random/rand#1435 (thanks @PatchMixolydic for talking withrandfolks!)The text was updated successfully, but these errors were encountered: