Subject: Re: [std-proposals] Making coroutines more explicit.
From: D Milos (dmilos_at_[hidden])
Date: 2019-08-28 02:45:39
Probably I miss something (or more).
For me corutine is just smart containers.
// Print 0 ... 9
for( auto const & n: cc )
cout << n << endl;
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 <
> On 21/08/2019 18.11, Robert Kubok via Std-Proposals wrote:
> 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)
> yield n++;
> would be equivalent to proposed:
> auto iota(int n = 0)
> 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
> 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 list run by herb.sutter at gmail.com
Standard Proposals Archives on Google Groups