Date: Fri, 12 Jun 2020 10:18:06 +0000
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>, 8.4.4.3 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 18.11.1.1, 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.
In the C++ Technical Specification N4680<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4680.pdf>, 8.4.4.3 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 18.11.1.1, 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.
Received on 2020-06-12 05:21:16