New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
P2502 std::generator: Synchronous Coroutine Generator for Ranges #1151
Comments
2021-12-13 Library Evolution TeleconP2168R3: P2502R0: 2021-12-13 Library Evolution Telecon Minutes Chair: Bryce Adelstein Lelbach Champion: Casey Carter Minute Taker: Ben Craig Start: 2021-12-13 8:12 Pacific Does this proposal have:
Template parameters in P2168:
Template parameters in P2502:
where:
The above are currently exposition only types, but some expressed a desire for them to be a part of the public interface. What should the reference type for Consider Add a table to Should the allocator parameter come before the Is there any precedent in the Standard Library for an allocator template parameter that's not the last template parameter? There's some suggestion that supporting recursive generators has an overhead for non-recursive use cases. Should Open Questions:
Topics to Polls:
POLL: Make
Attendance: 27 # of Authors: 1 Author Position: WA Outcome: No consensus. This topic needs further discussion in future revisions. POLL: Put
Attendance: 26 # of Authors: 1 Author Position: WF Outcome: No consensus. This topic needs further discussion in future revisions. End: 9:30 SummaryToday we discussed P2502, an updated proposal for We discussed some remaining open questions, notably:
We polled on the position of OutcomeWe will continue design review of P2502 |
P2502R0:
|
Strongly Favor | Weakly Favor | Neutral | Weakly Against | Strongly Against |
---|---|---|---|---|
2 | 3 | 3 | 4 | 4 |
Attendance: 21
# of Authors: 1
Author Position: 1x WA
Outcome: No consensus.
We'll retake the poll as some may have misunderstood it.
If the next poll is inconclusive, poll the nuclear option.
POLL: generator<T>
(where T
isn't a reference type) should have a reference type of const T&
.
Strongly Favor | Weakly Favor | Neutral | Weakly Against | Strongly Against |
---|---|---|---|---|
5 | 4 | 3 | 2 | 2 |
Attendance: 21
# of Authors: 1
Author Position: 1x SF
Outcome: No consensus.
POLL: generator<T>
(where T
isn't a reference type) should be ill-formed in its first release.
Strongly Favor | Weakly Favor | Neutral | Weakly Against | Strongly Against |
---|---|---|---|---|
0 | 7 | 6 | 3 | 0 |
Attendance: 21
# of Authors: 1
Author Position: 1x WF
Outcome: No consensus.
POLL: The first generator we release must support yielding nested generators.
Strongly Favor | Weakly Favor | Neutral | Weakly Against | Strongly Against |
---|---|---|---|---|
1 | 1 | 6 | 9 | 1 |
Attendance: 21
# of Authors: 1
Author Position: 1x N
Outcome: Weak consensus against.
End: 14:33
Summary
Today we continued our discussion of the new generator
proposal, P2502. Since our last review, a small group of stakeholders met to discussion the proposal, but unfortunately became deadlocked on one major question: for the simplest spelling of a generator, which we expect to be most commonly used, what should the reference type generator<T>
's ranges and iterators be when T
is not a reference type?
There are five different options:
T
: This is a performance pitfall, as you'll make a copy every time an iterator is dereferenced. This was proposed in earliergenerator
proposals, but no one is currently advocating for this.const T&
: This avoids making a copy on every dereference, and is what is currently proposed. However, this approach is problematic with move-only types such asunique_ptr
that you may wish to move out of agenerator
iterator. We polled this option and the outcome was inconclusive.T&
: This seems a bit nonsensical and hazardous, but it appears to be what at least some existing implementations do.T&&
: This would avoid copies in the common case and work for move-only types. However, it presents a number of safety and correctness concerns; what happens if you move the value on the first dereference, and then dereference again later? We polled this option and the outcome was inconclusive.const T&
by default, but you can convert it to a range ofT&&
. This would presumably require some cleverness and a flag for bookkeeping. We didn't poll this option because it was a new idea that required further evaluation.- Make
generator<T>
ill-formed whenT
is not a reference type. If we can't agree on the semantics, then we could just require users to be specific about what they want. We polled this option, and while we didn't have consensus, there was some indication that we may be able to eventually get to consensus in favor of this.
Regardless of what we decide for this case, you would still be able to specify what you want, e.g.generator<T&&>
, generator<T const&>
, or generator<string_view, void, string>
.
We also briefly discussed whether or not we needed the first generator type that we ship in the Standard Library to support yielding nested generators. Some are concerned about performance issues that may arise from yielding nested generators, as compilers may not be able to optimize such patterns. Others felt that a generator that doesn't support yielding nested generators is easy to write and may not be worth standardizing. We had consensus that it was not a hard requirement for the first generator we ship to support yielding nested generators. The authors should explore whether removing this requirement would simplify the proposal.
Finally, we had a frank discussion about the likelihood of getting any generator type into C++23. The chair pointed out that it is the end of December 2021 and C++23 has to be feature complete by February 2022. If we want something in C++23, we'll have to be willing to compromise and limit the scope of the feature. Even if we do that, it seems unlikely that we'll be able to land something before the feature complete date.
However, as coroutines library support is a plenary approved priority, we will continue working on it in January. We'll use the last two Library Evolution telecons of January to review the next revision of the proposal. If we do decide to ship something in C++23, we would have to run a short week-long electronic poll to confirm that decision before the February 2022 deadline.
Outcome
Bring a revision of P2502R0 (std::generator
), with the guidance below, to Library Evolution for further design review.
- Find a solution that can get consensus for the default reference type for
generator<T>
whenT
is not a reference type. - Explore whether dropping support for yielding nested generators simplifies the proposal.
- Document existing field experience, and get more of it.
2022-01-25 Library Evolution TeleconP2502R1: P2529R0: 2022-01-25 Library Evolution Telecon Minutes Chair: Gašper Ažman Champion: Casey Carter (P2502) and Mathias Stearn (P2529) Minute Taker: Bronek Kozicki Poll: Rename
Name stays. Poll: We are OK with
Poll: We are OK with
Poll: We are OK with
Poll: Forward P2502R1 to LWG (with
Next StepsTake an electronic poll to send P2502R1 ( |
P2502R1 std::generator: Synchronous Coroutine Generator for Ranges (Casey Carter) |
2022-01 Library Evolution Electronic Poll OutcomesSend [P2502R1] (std::generator) to Library Working Group for C++23, classified as a focus ([P0592R4] bucket 1 item)
Consensus in favor. |
@JeffGarland how confident are we that we'll get to this in time for C++23? |
It's obviously a high priority, but I've asked @dietmarkuehl if he could run some pre-review outside of regular LWG group time to make refinements before we see it in full group. I believe he will try to pick that up after ACCU (currently ongoing) - we should see if @CaseyCarter could participate |
Thanks. I just wanted to understand so we set expectations correctly.
…--
Bryce Adelstein Lelbach aka wash (he/him/his)
US Programming Language Standards (PL22) Chair
ISO C++ Library Evolution Chair
HPC Programming Models Architect @ NVIDIA
--
On Thu, Apr 7, 2022, 19:54 Jeff Garland ***@***.***> wrote:
It's obviously a high priority, but I've asked @dietmarkuehl
<https://github.com/dietmarkuehl> if he could run some pre-review outside
of regular LWG group time to make refinements before we see it in full
group. I believe he will try to pick that up after ACCU (currently ongoing)
- we should see if @CaseyCarter <https://github.com/CaseyCarter> could
participate
—
Reply to this email directly, view it on GitHub
<#1151 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADBG4RFDODAF2KQETCWRGLVD5YU3ANCNFSM5KEJJUCQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Yes, absolutely - I've been trying to make time for an editorial pass before LWG review, this will make it easier. |
LWG completed a number of small group and 2 large group reviews on 2022-06-03 -- approving for C++23. Notes from 04-26 small group https://wiki.edg.com/bin/view/Wg21telecons2022/P2502-20220426 Poll: Adopt P2502R2 std::generator for C++23
|
P2502R2 std::generator: Synchronous Coroutine Generator for Ranges (Casey Carter) |
P2502R0 std::generator: Synchronous Coroutine Generator for Ranges (Casey Carter)
The text was updated successfully, but these errors were encountered: