Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: Why can't I understand what coroutines are? Date: Fri, 09 Aug 2019 18:11:52 -0700 Organization: A noiseless patient Spider Lines: 41 Message-ID: <86y301963r.fsf@mailhub.linuxsc.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="4bad90a7c43721789c432acb03dbc8ee"; logging-data="30216"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19PqRBECoVOvNBBZzEixg/rbxyxao0zOQs=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:n2vMj4He+wvpn2ohMAm0dHRc0dM= sha1:tGQFewI4Y2LduW+ODpRUVnkPB2Y= Xref: csiph.com comp.lang.c++:67508 "Alf P. Steinbach" writes: > On 07.08.2019 00:38, Stefan Ram wrote: > >> "Alf P. Steinbach" writes: >> >>> I'll address the conceptual only. >> >> Not wanting to contradict anything, >> just as an extension: >> >> A coroutine is a function that contains >> either a coroutine-return-statement or >> an await-expression or a yield-expression. > > You mean, "A C++20 coroutine is...". > > General implementations of coroutines do not have that or > corresponding restriction. > > Even if the restriction is a special case of coroutines, I think > it can be argued that "coroutine" is a misnomer for the C++20 > thing. :-) [...] Yes, and it's an easy argument to make. The C++ construct I have seen described bears almost no resemblance to coroutines as they were originally described (I first read about them in Knuth v. 1). A C++20 "coroutine" is more like a detachable, resumable function, not at all like the symmetric arrangement of mutually calling functions described in Knuth. To be fair, it's probably worth mentioning that in those days (and especially in Knuth's TAOCP), call linkage was a lot more static, and what we now take for granted in the way of automatic storage was often nowhere to be seen in many program environments. Call stack? Local variables? Reentrant functions? These elements are pretty much not found in environments where coroutines were applied, and vice versa. It's hard to unify these two kinds of control structures. So it isn't surprising that "coroutine" takes on a rather different form in C++, compared to what coroutines were originally.