C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] Making coroutines more explicit.
From: Avi Kivity (avi_at_[hidden])
Date: 2019-08-27 12:00:32


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 list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups