Probably I miss something (or more).
For me corutine is just smart containers.

counting_container cc{0,10};
// Print 0 ... 9
for( auto const & n: cc )
  cout << n << endl;


My thought.
There are: std::begin, std::end. Just overload them.
This feature/ability should be provided on library level not core.

On Tue, Aug 27, 2019 at 7:00 PM Avi Kivity via Std-Proposals <std-proposals@lists.isocpp.org> wrote:


On 21/08/2019 18.11, Robert Kubok via Std-Proposals wrote:
Hello,
I have a proposal: make corotines more explicit in use, than it is proposed right now. The thing is: a function is treated as coroutine, when a 'co_yield' or 'co_return' keyword is used inside callable object's body. Whether a function is a coroutine or not, is determined by it's body, not by it's definition. In my opinion this is a language flaw. Therefore I suggest creating a new keyword: 'coroutine', which is going to be a type-specifier to a function or lambda expression and then, changing the upcoming keywords related to coroutines ('co_await', 'co_yield', 'co_return' to 'await', 'yield' and 'return' respectively). As always, it is better to see the syntax in action, so there's the example:

coroutine auto iota(int n = 0) 
{
    while(true)
        yield n++;
}

would be equivalent to proposed:

auto iota(int n = 0) 
{
   while(true)
      co_yield n++;
}

Or with lambda expression:
auto getFive = []() coroutine // in the same place as 'constexpr' keyword
{
    return 5;
};

which of course would be equivalent to:
auto getFive = []()
{
    co_return 5;
}

Why 'coroutine' keyword? Firstly, coroutine should be specified by it's declaration, not by it's body as it is proposed right now.


Why is that? Suppose a function returns a future<foo>. Why should it be part of the declaration? The function can choose to use a coroutine, call std::async(), or even std::make_ready_future<foo>. Why should it declare how it intends to implement its functionality?


I'd agree with moving having a coroutine keyword in the function definition.


Secondly, it makes syntax more clear and understandable, as 'await' is easier to read and write, than 'co_await' etc. Also it much more intuitive, especially for C++ newcomers. At last, this solution makes language more extensible in the future. For example, what if asynchronous execution would be provided by processor manufacturers? Then we would just add 'async' specifier and use 'yield', 'await' and 'return' just as we would use it with coroutines.



--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals