C++ Logo

STD-DISCUSSION

Advanced search

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>, 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.



STD-DISCUSSION list run by herb.sutter at gmail.com

Older Archives on Google Groups