Description
Full name of submitter: Artyom Kolpakov
Reference: [dcl.fct.def.coroutine] paragraph 7
Issue description:
According to the current working draft of the standard, clause dcl.fct.def.coroutine#7:
“The expression promise.get_return_object() is used to initialize the returned reference or prvalue result object of a call to a coroutine. The call to get_return_object is sequenced before the call to initial_suspend and is invoked at most once.”
This wording has an ambiguous reading. From my point of view, the result of the coroutine call should be initialized along with the call to get_return_object() before the call to initial_suspend. However, compiler developers may have a different opinion (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908, llvm/llvm-project#98744), that the result of the promise.get_return_object() call can be saved and the initialization of the returned coroutine object can be done after the call to initial_suspend. This can lead to undefined behavior unexpected by developers
For example, I want to use the same promise-type for different coroutines and return promise-type& from get_return_object(), which is used in the constructor of the returned coroutine object. The reference is saved and initialization is deferred. If the coroutine is not suspended at initial_suspend, continues executing to the end and destroyed, the reference to the promise will become dangling
Suggested resolution:
There are two solutions to this. If my view reflects the intent of the standard, add to the paragraph that the initialization of the result is also sequenced before the call to initial_suspend. Otherwise, add to the paragraph that it is unspecified that the initialization of the result is sequenced before or after the call to initial_suspend, perhaps with the addition of a note that this could lead to the use of dangling references