220 21480 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Resumable expressions p0114r0 vs async/await P0057R0 Date: Fri, 9 Oct 2015 08:21:56 -0700 (PDT) Lines: 101 Approved: news@gmane.org Message-ID: References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> <401aa118-ed0b-4c7b-92cf-3fbd706eff9d@isocpp.org> <1d15dbc4-e0c1-4df1-86db-014e11f14d26@isocpp.org> <1bf00a8f-5f20-43de-a319-2712ab34eafd@isocpp.org> <36f46c03-b1f1-4230-b686-a7a9a1c491cb@isocpp.org> <9e17f8a6-4f5b-47dd-9f76-a4675a5ede3c@isocpp.org> <1105ae90-7e2b-49be-b88e-84493c9a1810@isocpp.org> <3a14727f-6b96-4ef6-a525-9c7c0b2872bc@isocpp.org> <74a572d9-a8bb-475e-baee-ad4e5d74150e@isocpp.org> <1c10388c-74fa-4a37-9ecf-000d87daab9c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_263_1513470719.1444404116424" X-Trace: ger.gmane.org 1444404121 31072 80.91.229.3 (9 Oct 2015 15:22:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Oct 2015 15:22:01 +0000 (UTC) Cc: german.diago@hubblehome.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBFNX36YAKGQEW4O56TY@isocpp.org Fri Oct 09 17:22:01 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZkZUe-00054E-9N for gclcip-std-proposals@m.gmane.org; Fri, 09 Oct 2015 17:22:00 +0200 Original-Received: by padez4 with SMTP id ez4sf155840034pad.0 for ; Fri, 09 Oct 2015 08:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=TOLdPtc2C3Tep5mYddnAl/QCxWMmQ6vsrrNiZr0Y+qA=; b=XwQctelIND8WTe+S7qsq8XU2hmFEirvJSLx+ZOmjF2brcV76cvhNRc6aoFM9PXJzdq eZ8WzdunHu3F8PqhNf2ra9GqU+B8ArtcPpiDfU/7eGYHpdvp/ckZMlusM90OMDbizGKt BBIB6jLVqPzLRYiRTkwGfPareJIAY6QXu9Kg4Og6CAMXw9uaf5WzD4WxNrSVX0wTNsNI FXWNDEbWAPwOvEEhFtZJqW+p8Bm1Uz+HlqQUK/6f1Uv76GKAr4JX3S4ztQoBiyVzlbST Bl2CLjebebTSvuD5m70auSXzwTRwDb0Z24C3hz1f3RhCr/3jlTjmGKYuvgcWLWeLtU2e /1mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=TOLdPtc2C3Tep5mYddnAl/QCxWMmQ6vsrrNiZr0Y+qA=; b=UnWIuiiDSaCxueDFhXJwBefA2siwqPuqJ56fnAQZKeCwi7Gk+rEzjla16GHJQZ3VxE QWjY/TH0SHKPPDWxuvL9H46bq2Th83uX7uat+wpaxtN/4S1dilDKenpDUC2UlPV5QdO6 XwzsJyCybSk9rDRWo0WrxyIa+WT8W9beP3BqaByx3/3V1+h64/jyF2HP3Uj9xiJQFQHr XmGUsj6ttflAlrHvZ65BlBrOSpH9hYc0BYLa+4DmkAWOnP7uZiAatQD4I/IcdTBlkTGC uVmP/7W55TxRVqk4eX7LynytrRpsRZNOFgrSOgif9Ovv+XqDQ57OlUWN79v9E1/D7OP0 Uwzg== X-Gm-Message-State: ALoCoQkXO5PbTGth8GaTPYI4BoNVZpXkqFre1ZXzoSmqRXE3bLSE1SN+Yqe4yvXZ3D2VBFh8yqFq X-Received: by 10.66.246.198 with SMTP id xy6mr11314367pac.36.1444404119119; Fri, 09 Oct 2015 08:21:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.66.202 with SMTP id h10ls545470igt.38.canary; Fri, 09 Oct 2015 08:21:57 -0700 (PDT) X-Received: by 10.50.79.166 with SMTP id k6mr141470igx.14.1444404117654; Fri, 09 Oct 2015 08:21:57 -0700 (PDT) In-Reply-To: <1c10388c-74fa-4a37-9ecf-000d87daab9c@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:21480 Archived-At: ------=_Part_263_1513470719.1444404116424 Content-Type: multipart/alternative; boundary="----=_Part_264_1755520863.1444404116424" ------=_Part_264_1755520863.1444404116424 Content-Type: text/plain; charset=UTF-8 On Friday, October 9, 2015 at 1:49:45 AM UTC-4, germa...@gmail.com wrote: > > What are the chances that we could capture the coroutines themselves in > variables, and make them copyable and movable? > I tend to see as a standard idiom to have objects that can be > copied/moved/compared, etc. that is the trend lately I think. > I do not mean the rest is not good, but why should we prevent these > semantics in the first place in coroutines? > If you're talking about value semantics, that doesn't make sense for coroutines. Remember that part of a coroutine's state is the stack. And stack variables are often references or pointers to other stack variables. You cannot effectively copy such a construct. And it's silly for the user to have to define a "copy constructor" for their call stack. That's why `coroutine_handle` has reference semantics. It just makes more sense for coroutines. That doesn't prevent you from being able to pass them (and any containing object) around. You can even have a `std::vector>` and resume each one in turn. Or to put it another way, just because you see `await` used to catch the coroutine promise returned by a coroutine does not mean you *have* to use it that way. > Also, I see the yield keyword. I am not sure how it works. > It returns a value and suspends the coroutine's execution at that point. If you're wondering about the details of how the value is passed to the coroutine promise and all, that's part of the proposal. -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_264_1755520863.1444404116424 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, October 9, 2015 at 1:49:45 AM UTC-4, ge= rma...@gmail.com wrote:
Wh= at are the chances that we could capture the coroutines themselves in varia= bles, and make them copyable and movable?
I tend to see as a standard i= diom to have objects that can be copied/moved/compared, etc. that is the tr= end lately I think.
I do not mean the rest is not good, but why should w= e prevent these semantics in the first place in coroutines?

If you're talking about value semantics, that doesn'= ;t make sense for coroutines. Remember that part of a coroutine's state= is the stack. And stack variables are often references or pointers to othe= r stack variables. You cannot effectively copy such a construct. And it'= ;s silly for the user to have to define a "copy constructor" for = their call stack.

That's why `coroutine_handle` has reference se= mantics. It just makes more sense for coroutines. That doesn't prevent = you from being able to pass them (and any containing object) around. You ca= n even have a `std::vector<generator<int>>` and resume each one= in turn.

Or to put it another way, just because you see `await` use= d to catch the coroutine promise returned by a coroutine does not mean you = have to use it that way.
=C2=A0
Also, I see the yield keyword. I am not sure how it w= orks.

It returns a value and suspends the corout= ine's execution at that point.

If you're wondering about the= details of how the value is passed to the coroutine promise and all, that&= #39;s part of the proposal.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_264_1755520863.1444404116424-- ------=_Part_263_1513470719.1444404116424-- .