P2502 std::generator: Synchronous Coroutine Generator for Ranges

[brycelelbach]

P2502R0 std::generator: Synchronous Coroutine Generator for Ranges (Casey Carter)

[brycelelbach]

2021-12-13 Library Evolution Telecon

P2168R3: std::generator

P2502R0: std::generator

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:

• Examples?
  • Yes.
  • Adding before/after examples might be helpful, as the author states that std::generator greatly reduces the amount of code you'd have to write for the examples.
• Implementation experience?
  • Yes, in third party libraries like CppCoro and Folly, but not in any major Standard Library.
• Usage experience?
  • Yes, in third party libraries like CppCoro and Folly, but not in any major Standard Library.
• Deployment experience?
  • Yes, in third party libraries like CppCoro and Folly, but not in any major Standard Library.
• Performance considerations?
  • Yes.
• Discussion of prior art?
  • Yes. Direct descendant of P2168, which builds on experience from third party libraries.
• Changes Library Evolution previously requested?
  • The paper considers and attempts to address open questions that arose during previous discussions.
• Wording?
  • Yes.
• Feature test macro?
  • Yes.

Template parameters in P2168:

template <class Ref,
          common_reference_with<Ref> Value = remove_cvref_t<Ref>,
          class Allocator = void>
class generator;

Template parameters in P2502:

template <class T,
          class Allocator = void,
          class U = void>
class generator;

where:

using Value = conditional_t<is_void_v<U>, remove_cvref_t<T>, U>;}
using Reference = conditional_t<is_void_v<U>,
                                conditional_t<is_reference_v<T>, T, const T&>,
                                T>;
using Yielded = conditional_t<is_reference_v<Reference>, Reference, const Reference&>;

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 generator<T> be when T is not a reference type? The paper currently proposes const T&; some suggest T&&.

Consider generator<string> - string&& would be odd reference type for a range. But for generator<unique_ptr<T>>, unique_ptr<T> const& would be odd.

Add a table to generator<meow> showing examples of what the reference type would be for some common cases of T, such as string, string&&, unique_ptr<T>.

Should the allocator parameter come before the U parameter?

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 generator support recursive generators, or should we add a separate type for that later?

Open Questions:

• Default reference type for generator<T>.
• generator support for recursion.
• Position of generator's allocator template parameter.
• Header for generator.

Topics to Polls:

• Position of the allocator template parameter.
• Header for generator.

POLL: Make generator's allocator template parameter the last template parameter.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
2	5	7	5	0

Attendance: 27

# of Authors: 1

Author Position: WA

Outcome: No consensus.

This topic needs further discussion in future revisions.

POLL: Put generator in <ranges> instead of adding a new <generator> header.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
3	7	2	8	1

Attendance: 26

# of Authors: 1

Author Position: WF

Outcome: No consensus.

This topic needs further discussion in future revisions.

End: 9:30

Summary

Today we discussed P2502, an updated proposal for std::generator. This new revision proposes a new approach for template parameterization, which seems to address some of the issues identified with prior revisions. It was received well.

We discussed some remaining open questions, notably:

• The default reference type for generator<T>.
• generator support for recursion.
• The position of generator's allocator template parameter.
• The header that generator should live in.

We polled on the position of generator's allocator template parameter and the header that generator should live in. Both polls were inconclusive; further discussion is needed.

Outcome

We will continue design review of P2502 generator at our next telecon.

[brycelelbach]

P2502R0: std::generator

P2502R0: std::generator

2021-12-21 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Casey Carter

Minute Taker: Ben Craig

Start: 2021-12-21 13:21 Eastern

Options for reference type for generator<T> where T isn't a reference type:

• const T& (Casey)
• T&& (Mathias)
• Some cleverness to allow us to do either, e.g. moving() (Tomasz)
• Make generator<T> ill-formed (nuclear option)

What do existing implementations do for reference type of generator<T>:

• CppCoro: T&.
• folly: T&.
• ranges v3: T.
• MSVC's experimental generator: const T&.

POLL: generator<T> (where T isn't a reference type) should have a reference type of T&& instead of const T&.

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:

1. T: This is a performance pitfall, as you'll make a copy every time an iterator is dereferenced. This was proposed in earlier generator proposals, but no one is currently advocating for this.
2. 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 as unique_ptr that you may wish to move out of a generator iterator. We polled this option and the outcome was inconclusive.
3. T&: This seems a bit nonsensical and hazardous, but it appears to be what at least some existing implementations do.
4. 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.
5. const T& by default, but you can convert it to a range of T&&. 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.
6. Make generator<T> ill-formed when T 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> when T 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.