C++ Coroutine TS Issues

Introduction

All proposed resolutions wording is relative to N4663 (ISO/IEC PDTS 22277).

Table of content

• Core issues with proposed wording: 2 6 7 8 18 21
• Core comments requesting rebase of a TS to C++17: 3 5 17
• Core comments (no action): 4
• LWG issues with proposed wording: 9 10 22 23
• LWG issues with no wording: 11 12 14 15 16 19 20
• Evolution issues with no wording: 1 13

Core Issues (with proposed wording)

2. Change to italics await-resume in 5.3.8/4

Section: 5.3.8 [expr.await] Status: Has wording Submitter: US002 Opened: 2017-06-05 Last modified: 2017-06-05

Proposed resolution:

Modify 5.3.8/4

The await-expression has the same type and value category as the await-resumeawait-resume expression.

6. Remove or update stateful allocator example in 8.4.4/12

Section: 8.4.4 [dcl.fct.def.coroutine] Status: Has wording Submitter: US006 Opened: 2017-06-05 Last modified: 2017-06-05

Issue:

Stateful allocators (pmr) do not work this way, there's no mechanism for allocator propagation to the captured state.

Strike section 12, or provide mechanism for holding allocator.

Proposed resolution:

Remove example 8.4.4/12

7. Fix generator example in 8.4.4/11

Section: 8.4.4/11 [dcl.fct.def.coroutine] Status: Has wording Submitter: US007 Opened: 2017-06-05 Last modified: 2017-06-05

Issue:

Is unhandled_exception() a requirement for a promise_type?

a) Call std::terminate if not present
or
b) Add unhandled_exception() to the complete example of promise_type in 8.4.4 paragraph 11, the generator example.

Discussion:

unhandled_exception() is required to be present in a promise_type. There are more mistakes in the example that are fixed in the proposed resolution. Also, required includes are added to make the example self contained and runnable in online compilers.

Proposed resolution:

#include <iostream>
#include <experimental/coroutine>

// ::operator new(size_t, nothrow_t) will be used if allocation is needed
struct generator {
  struct promise_type;
  using handle = std::experimental::coroutine_handle<promise_type>;
  struct promise_type {
    int current_value;
    static auto get_return_object_on_allocation_failure() { return generator{nullptr}; }
    auto get_return_object() { return generator{handle::from_promise(*this)}; }
    auto initial_suspend() { return std::experimental::suspend_always{}; }
    auto final_suspend() { return std::experimental::suspend_always{}; }
    void unhandled_exception() { std::terminate(); }
    void return_void() {}
    auto yield_value(int value) {
      current_value = value;
      return std::experimental::suspend_always{};
    }
  };
  bool move_next() { return coro ? (coro.resume(), !coro.done()) : false; }
  int current_value() { return coro.promise().current_value; }
  generator(generator const&) = delete;
  generator(generator && rhs) : coro(rhs.coro) { rhs.coro = nullptr; }
  ~generator() { if (coro) coro.destroy(); }
private:
  generator(handle h) : coro(h) {}
  handle coro;
};
generator f() { co_yield 1; co_yield 2; }
int main() {
  auto g = f();
  while (g.move_next()) std::cout << g.current_value() << std::endl;
}

8. Note about possibly undefined behaviour

Section: 8.4.4/11 [dcl.fct.def.coroutine] Status: Has wording Submitter: US008 Opened: 2017-06-05 Last modified: 2017-06-05

Proposed change:

Modify note in 8.4.4/11:

If a coroutine has a parameter passed by reference, resuming the coroutine after the lifetime of the entity referred to by that parameter has ended is likely to result in undefined behavior.

Proposed resolution:

18. In intro.refs use required text from ISO directive part2

Section: 2 [intro.refs] Status: Has wording Submitter: CA018 Opened: 2017-06-05 Last modified: 2017-06-05

Issue:

The form required by ISO/IEC Directives, Part 2, 2016 subclause 15.5.1 is not followed.

Use the text provided by the Directives.

Proposed resolution:

Modify [intro.refs] paragraph 1 as follows:

The following referenced document is indispensable for the application of this document. For dated references, only the edition cited applies.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

21. Wording of 'co_return <expr>;' statement for expressions of type void implies that <expr> is not evaluated

Section: 6.6.3.1 [stmt.return.coroutine] Status: Has wording Submitter: Lewis Baker Opened: 2017-03-11 Last modified: 2017-06-19

Issue:

This wording seems to indicate that expr is not evaluated in co_return expr if the expression has type void, since expr does not occur in the translation. I assume this was not the intention here.

Perhaps there needs to be an extra case here to explicitly state what co_return expr; translates to if the type of expr is void?

Proposed resolution:

Insert new bullet in [stmt.return.coroutine] after 2.2 as follows:

(2.1) — S is p.return_value(braced-init-list), if the operand is a braced-init-list;
(2.2) — S is p.return_value(expression), if the operand is an expression of non-void type;
(2.3) — S is expression,return_void(), if the operand is an expression of void type;
(2.34) — S is p.return_void(), otherwise;

Core comments requesting rebase to C++17

3. Update range based for statement after C++17

Section: 6.5.4/1 [stmt.ranged]Status: Comment Submitter: US003 Opened: 2017-06-05 Last modified: 2017-06-05

Comment:

Update range based for statement after C++17

5. Modify co_return grammar to match C++17

Section: 6.6.3.1 [stmt.return.coroutine]Status: Comment Submitter: US005 Opened: 2017-06-05 Last modified: 2017-06-05

Comment:

Simplify the grammar for

coroutine-return-statement:
   co_return expression_opt_;
   co_return braced-init-list;
    

coroutine-return-statement:
   co_return co_return expr-or-braced-init-list opt;
    

17. Rebase entire TS on C++17

Section: Status: Comment Submitter: US017 Opened: 2017-06-05 Last modified: 2017-06-05

Comment:

We are in the process of balloting the final text of the next C++ standard, provisionally ISO/IEC 14882:2017. We should hold back publishing this TS long enough to rebase on the text of the new standard.

Other than updating this reference, the change is almost entirely updating section numbers and crossreferences. The normative changes would be

• updating the range based 'for' loop syntax;
• the text for a 'return' statement would need adjusting;
• the wording on restrictions with respect to longjmp should be reviewed;
• hash support for coroutine_handle should be updated with the “enabled” terminology.

Core comments (no action)

4. It would be good to minimize undefined behaviour

Section: 6.6.3 6.6.3.1 8.4.4 8.11.2.5 18.10 18.11.2.5 Status: Comment Submitter: US004 Opened: 2017-06-05 Last modified: 2017-06-05

Comment:

There are many new cases of undefined behaviour introduced by the TS which are somewhat easily triggered by independent parts of the mechanisms, e.g., the result type of the coroutine interacting through the promise_type to allow flow of control to run off the end of a coroutine. In general it would be good to minimize undefined behaviour.

No action for now. However, experience with TS implementation may allow reducing UB. This should form part of any review for integrating coroutines as part of a future standard.

LWG Issues (with proposed wording)

9. Move row in the language support table

Section: 18.1 [support.general] Table 30 Status: Has wording Submitter: CA009 Opened: 2017-06-05 Last modified: 2017-06-05

Issue:

Proposed resolution:

10. Specify the exact behaviour of user-customization of coroutine_traits.

Section: 18.11.1 [coroutine.traits] Status: Has wording Submitter: US010 Opened: 2017-06-05 Last modified: 2017-06-05

Issue:

  struct promise_type {
    suspend_never initial_suspend() { return {}; }
    suspend_always yield_value(int value) { ...; return {}; }
    ...
  };

  coro f(bool cond) {
    if (cond)
      co_return 42;
    else
      co_return;
  }