On Tue, Aug 26, 2025 at 10:51 AM 梁家铭 via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Hi, 
Recently I find that it's illegal to write std::generator code like:

std::generator<int> Test()
{
    std::vector<int> vec{ 0, 1, 2 };
    co_yield std::ranges::elements_of(vec);
}

which is very counter-intuitive. This code example is even adopted from the std::generator proposal (P2502R2, page 16), which also thinks it should be legal. In other words, the proposal seems to be inconsistent in intention and wording, so I think there should be a DR to fix it.

Let me briefly analyze what happens first. Remember that here std::generator<int>::yielded == int&&.

So in current specification of std::generator, the standard regulates that for .yield_value() of the promise type (see [coro.generator]):
Effects: Equivalent to:auto nested = [](allocator_arg_t, Alloc, ranges::iterator_t<R> i, ranges::sentinel_t<R> s) -> generator<yielded, void, Alloc> { for (; i != s; ++i) { co_yield static_cast<yielded>(*i); } }; return yield_value(ranges::elements_of(nested( allocator_arg, r.allocator, ranges::begin(r.range), ranges::end(r.range))));
So here it's legal, since static_cast<yielded>(*i) (i.e.static_cast<int&&>(int&)) is legal. However, the constraints of .yield_value() reject it:
template<ranges::input_range R, class Alloc> requires convertible_to<ranges::range_reference_t<R>, yielded> auto yield_value(ranges::elements_of<R, Alloc> r);

Here ranges::range_reference_t<R> is int&, and yielded is int&&. That is, int& is explicitly convertible to int&& (which is fine for std::generator), but not implicitly convertible to int&&, making the constraint fail.
So I think there should be a DR to loosen the constraint to make explicit conversion enough.
[This email is also sent to author of P2502]

I don't know much about this stuff, but it seems like you're right.
All of this stuff was introduced in the C++23 cycle, right? There's nothing about your example that requires C++26 (and thus no urgency to fix it within the C++26 cycle that is about to close)?
Seems like this could be handled via an LWG issue, if someone were to request one.

I notice that both of these tweaked examples do compile, not that either of them is desirable:

std::generator<int> Test2() {
    std::vector<int> vec = { 0, 1, 2 };
    co_yield std::ranges::elements_of(vec | std::views::as_rvalue);
}
std::generator<float> Test3() {  // hat tip to Timur Doumler for publicizing this quirk of reference binding
    std::vector<int> vec = { 0, 1, 2 };
    co_yield std::ranges::elements_of(vec);
}

–Arthur