On Tue, Aug 26, 2025 at 10:51 AM 梁家铭 via Std-Proposals <
std-proposals_at_[hidden]> 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]
> <https://eel.is/c++draft/coro.generator#promise-13>):
> *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
> <https://eel.is/c++draft/range.refinements#concept:input_range> R, class
> Alloc> requires convertible_to
> <https://eel.is/c++draft/concept.convertible#concept: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.
>

Using `std::is_constructible_v` for the constraint would already be
questionable: it would be able to call explicit constructors and explicit
conversion functions. But that still wouldn't be enough for what you're
asking for. Conversion from `int&` to `int&&` requires an explicit cast. I
do not think `yield_value` should accept ranges whose reference type has to
be explicitly casted to the yielded type. That would allow all sorts of
questionable conversions, like `Base*` to `Derived*`.

However, I agree that there does seem to be a problem here. We can
`co_yield` an lvalue or rvalue of type `int` from this generator coroutine,
so the fact that this code doesn't compile is surprising and seems
unintended. `co_yield`ing an lvalue here is specifically supported by the
following overload of `yield_value`:

    auto yield_value(const remove_reference_t<yielded>& lval)
      requires is_rvalue_reference_v<yielded> &&
        constructible_from<remove_cvref_t<yielded>, const
remove_reference_t<yielded>&>;

It seems to me that the constraint for the range overload ought to be
consistent with the single-value case: if either of the two single-value
overloads is viable (or if both are viable and the overload resolution is
unambiguous) then the range ought to be accepted.

[This email is also sent to author of P2502]
> Liang Jiaming
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*