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
P2168 std::generator: Synchronous Coroutine Generator for Ranges #865
Comments
P2168R0: 2020-05-26 Library Evolution Telecon Minutes Chair: Nevin Liber Champion: Lewis Baker & Corentin Jabot Minute Taker: Ben Craig Start Review: 2020-05-26 10:00 Pacific POLL: Recursive generators should use the syntax
Author's position: A (CJ), F (LB) Attendance: 32 That has consensus for. SA: Adds zero information to the program and more characters to get wrong. POLL: Recursive generators should use the syntax
Author's position: SF (CJ), N (LB) Attendance: 32 SA: Automatic recursive nesting of arbitrary ideas has proved tricky in the past with future.then. That has consensus for.
POLL: Generator should be in header
Author's position: A (CJ), SF (LB) Attendance: 32 SA: Just a perf issue of having too many small headers That has consensus for. End: 11:40 SUMMARY:
OUTCOME: Bring a revision of P2168R0 (
|
P2168R1 generator: A Synchronous Coroutine Generator Compatible With Ranges (Corentin Jabot, Lewis Baker) |
2021-02-23 Library Evolution TeleconP2168R2: 2021-02-23 Library Evolution Telecon Minutes Chair: Bryce Adelstein Lelbach Champion: Lewis Baker and Corentin Jabot Minute Taker: Mark Hoemmen Start: 2021-02-23 10:09 Pacific Does this proposal have:
Changes that Library Evolution requested from R0:
It appears the authors have addressed all the changes Library Evolution requested last time. Implicit conversion between generator element types. Do we want that? Are there any complications?
We could always add something that only yields generators of the same generator type, e.g. Are we okay with the split reference/value type template parameters? Necessary to support proxy reference types. Precedence for split reference/value type template parameters:
Precedence for proxy reference types in the standard:
Could we have a Maybe we could have a POLL:
Attendance: 28 # of Authors: 2 Author Position: 2x SF Outcome: That has consensus. Is there precedence for We'll resume the review in future weeks. End: 11:04 SummaryDuring this review of First, we discussed the differences between Next, we discussed the split reference/value type template parameters of OutcomeBring a revision of D2168R2 (
Library Evolution will resume its review of this revision D2168R2 ( |
2021-03-08 Library Evolution TeleconP2168R2: 2021-03-08 Library Evolution Telecon Minutes Chair: Bryce Adelstein Lelbach Champion: Lewis Baker & Corentin Jabot Minute Taker: Ben Craig Start: 2021-03-08 10:02 Pacific Does this proposal have:
Is there precedence for Can the allocator parameter have some unspecified default type instead? Why not use PMR for allocator type-erasure? Why take a typed allocator instead of an untyped memory resource? Why not Should we add a new If we only had an The underlying problem is that you can't get access to the allocator to rebind it. POLL:
Attendance: 27 # of Authors: 2 Author Position: 2x SF Outcome: No consensus in either direction. POLL: If
Attendance: 25 # of Authors: 2 Author Position: SF, WF Outcome: Consensus in favor. WA: This is novel, and I'm not sure why we need it here. If I have to use any allocator with a WA: I think it adds overhead, both when you use and when you don't. POLL:
Attendance: 25 # of Authors: 2 Author Position: WF, N Outcome: Weak consensus against. EXPLORE: The type that indicates that EXPLORE: EXPLORE: Explore two separate generator types: nested generators (which uses symmetric transfer) and non-nested generators (which doesn't use symmetric transfer). FUTURE POLL: We will resume discussion of this revision in 2021-04. It will probably be at a special time to accommodate Lewis's time zone. End: 11:30 SummaryWe continued our review of P2168R2 The current proposal is for We also discussed the implications of allocator support on By the end of our discussion, it was unclear if we had consensus that OutcomeBring a revision of P2168R2 (
Library Evolution will resume its review of this revision P2168R2 ( |
2021-04-19 Library Evolution TeleconD2168R3: 2021-04-19 Library Evolution Telecon Minutes Chair: Bryce Adelstein Lelbach Champion: Lewis Baker and Corentin Jabot Minute Taker: Gasper Azman Start: 2021-04-19 08:07 Pacific Does this proposal have:
What should the order of value/reference type template parameters be? The current order is reference then value. If we make value then reference, can we pick a reasonable default for what the reference type will be? Instead, we could make the iterators always return references, because you have to store the value in the promise anyways. Then the first template parameter can name the storage type. You'd still need a split value and reference type - consider wanting Matthias' model: the value type is what you pass to the Have Matthias, David, and authors write a section of the paper that explores all the options for value/reference semantics of
Future Poll Ideas:
Examples we want to see:
Can input iterators be dereferenced multiple times? Wording Review:
Should
End: 09:39 SummaryIn this review of P2168 In addition to the model in the paper at present, a few alternative models were suggested during the discusison. We instructed the authors to add a section to the paper considering these different models and their tradeoffs in greater detail, and identified We also discussed the order of the value type and reference type parameter, if they are to both exist. Additionally, we began reviewing the wording of the paper to prepare it for advancement to Library. OutcomeBring a revision of P2168R3 (
|
P2168R2 generator: A Synchronous Coroutine Generator Compatible With Ranges (Corentin Jabot, Lewis Baker) |
P2168R3 generator: A Synchronous Coroutine Generator Compatible With Ranges (Corentin Jabot, Lewis Baker) |
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:
Key Insights: 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 |
P2168R0 std::generator: Synchronous Coroutine Generator for Ranges (Corentin Jabot)
The text was updated successfully, but these errors were encountered: