C++ Logo

STD-PROPOSALS

Advanced search

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.

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_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>



STD-PROPOSALS list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups