Subject: Is it an undefined behavior that the return type of a coroutine doesn't own a member type: promise_type in C++20 standard?
From: Ðí ´«Ææ (legend-k_at_[hidden])
Date: 2020-06-12 05:18:06
Hi, this is my first time to use the mailing question to ask questions. If I do anything wrong, please remind me directly.
In the C++ Technical Specification N4680<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4680.pdf>, 126.96.36.199 writes:
For a coroutine f that is a non-static member function, let P1 denote the type of the implicit object parameter (13.3.1) and P2 ... Pn be the types of the function parameters; otherwise let P1 ... Pn be the types of the function parameters. Let p1 ... pn be lvalues denoting those objects. Let R be the return type and F be the function-body of f, T be the type std::experimental::coroutine_traits, and P be the class type denoted by T::promise_type. Then, the coroutine behaves as if its body were:
This paragraph seems like that every coroutine should have a promise type. But in 188.8.131.52, it says:
The header defines the primary template coroutine_traits such that if ArgTypes is a parameter pack of types and if R is a type that has a valid (14.8.2) member type promise_type, then coroutine_traits has the following publicly accessible member:
using promise_type = typename R::promise_type;
Otherwise, coroutine_traits has no members.
It seems like that it is legal that the coroutine_traits<R,ArgTypes...> would not own a promise_type.
So it is confusing me that whether it is an undefined behavior that the return type of a corouinte don't own a promise_type.
STD-DISCUSSION list run by email@example.com
Older Archives on Google Groups