P2168 std::generator: Synchronous Coroutine Generator for Ranges

[brycelelbach]

P2168R0 std::generator: Synchronous Coroutine Generator for Ranges (Corentin Jabot)

[brycelelbach]

P2168R0: std::generator

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 co_yield elements_of(gen), performance the same as co_yield gen as specified in the paper

SF	WF	N	WA	SA
5	10	3	3	1

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 co_yield gen

SF	WF	N	WA	SA
7	4	9	4	1

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.

co_yield elements_of(gen) has stronger consensus than co_yield gen.

POLL: Generator should be in header <generator>

SF	WF	N	WA	SA
14	5	3	1	1

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:

• A lot of discussion around "recursive generators", where a co_yield of the same type of generator would produce its elements. There was more support for doing so with a syntactical construct such as co_yield elements_of(gen) (instead of co_yield gen as presented in the paper) and the authors will investigate generalizing that to being able to pass in other views.
• The room was generally fine with having the optional second template parameter specifying the value type, but would like to see more motivation in the next revision of the paper.
• Seemed to be general desire to support a single generator type that supports yielding nested generators, rather than two separate generator types, on condition that we show that compilers are able to optimize/inline similarly.
• The destructor for generator may not be O(1), as required by [range.view]. While it will need wording to that effect, this is fine for generator, but is discouraged in most other views.
• Strong preference for putting generator in its own header.
• Ran out of time to do more than a cursory examination of the wording.

OUTCOME: Bring a revision of P2168R0 (std::generator), with the guidance below, to Library Evolution for further design review.

• Explore an explicit syntax for recursive generators, e.g. co_yield elements_of(gen) instead of co_yield gen, as a way to increase consensus.
• Put std::generator in a new header <generator>.
• Clarify that std::generator::~generator may not be O(1), which violates range requirements.

[wg21bot]

P2168R1 generator: A Synchronous Coroutine Generator Compatible With Ranges (Corentin Jabot, Lewis Baker)