220 21227 <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Germ=C3=A1n_Diago?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Resumable expressions p0114r0 vs async/await P0057R0 Date: Sat, 3 Oct 2015 04:41:18 -0700 (PDT) Lines: 110 Approved: news@gmane.org Message-ID: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2198_465842834.1443872478474" X-Trace: ger.gmane.org 1443872490 19464 80.91.229.3 (3 Oct 2015 11:41:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 Oct 2015 11:41:30 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDC2VXM4YYDRBX75X2YAKGQEN2ZWPXQ@isocpp.org Sat Oct 03 13:41:30 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZiLBu-0008NL-Pi for gclcip-std-proposals@m.gmane.org; Sat, 03 Oct 2015 13:41:26 +0200 Original-Received: by vkat63 with SMTP id t63sf164123866vka.0 for ; Sat, 03 Oct 2015 04:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id: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=zIpVVo6stnEK+Ex2r+iwykxyoI734W+LJR5ZmY3DBUU=; b=JXh3Bs7hg+ThsWmscS+CRnz0Nl8HqieCXRb/unIYWc8T1TZ3NK0ltf15uANOeYn52W RVHzEyxkngCSii/brQWJiujsPeTLPV8FUTPPDbR7Mxt3E/O6aR3cgYS4RKuKNo8EYMpZ 0DHH+QNxXkqrtp0iOIh2wonRemuWXvaMb7XVaDGSOdjVmIU9V74dGr+u16fqdsd4/FS2 72NU3f366Vh34nBK3vNeaLNzym6eAHUem4xGFkAlfQCGOZGCb25WuwtwXznYF3I8DG56 lt3f6xhDp1WVr+1RGL9FrMj6k/+vMYp26HtQQRdfeYzzjCjVXtBKQErDrWQngrVPwsnt brfg== 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:message-id: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=zIpVVo6stnEK+Ex2r+iwykxyoI734W+LJR5ZmY3DBUU=; b=XPr9t0t1ki9jr5fmjsOR3DpNF1aRBrXjM7A2XhSambOSc67ydpZvKDrnMDlXkMXDUX nwfzjzYqrDO9eeKNPInX/lhNx3Vd3BETGIYacX8SMvSYHXy2zvbdA10PxGrSwg+UzDca NAM8SdaXA65clQWTuqgdzZdaspIl3v+iJa25a+pmswGxBEszc3qKGuxhBI5lgXbby0vc p6O76xObZ0e3bp4VZouNtCK0kd46wQ0+2CFq3KockIBUvVkSc0YUhEaJD9HJ5/essZ7c uONKfxCQLcsOj9mS+n10UFYGazNzQhxB1TwgpKT73PnHvyX5vpZMsgUNT/05sO7k8UN1 pOHA== X-Gm-Message-State: ALoCoQkYDEIDcwlXJMlL7QKgfZFRhKW7580vdzokuW0PynQ/s3pXv7J+Eh94tYnVebzWBXRoOnAp X-Received: by 10.13.223.129 with SMTP id i123mr17349431ywe.33.1443872480160; Sat, 03 Oct 2015 04:41:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.46.99 with SMTP id i96ls1066576ioo.37.gmail; Sat, 03 Oct 2015 04:41:19 -0700 (PDT) X-Received: by 10.50.122.103 with SMTP id lr7mr16617igb.10.1443872479213; Sat, 03 Oct 2015 04:41:19 -0700 (PDT) X-Original-Sender: germandiago@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:21227 Archived-At: ------=_Part_2198_465842834.1443872478474 Content-Type: multipart/alternative; boundary="----=_Part_2199_66584921.1443872478474" ------=_Part_2199_66584921.1443872478474 Content-Type: text/plain; charset=UTF-8 Hello everyone, I do not mean to start a flame here, but I am still wondering why the coroutines from P0057R0 are still being considered. For what it is worth, I find the paper from Christopher Kohlhoff very clarifying, very well reasoned, and providing alternatives for all the important use cases from P0057R0 with superior implementations. I still share the same concerns as before for P0057R0, mainly: - mandatory type erasure. - as Christopher mentions, embedding a scheduler into the language is not a nice thing. - viral await is also something to be aware of. On top of that, he shows alternatives for implementations: 1. Generators (reified and type-erased). 2. await. You also have yield as an object, which I think can be of advantage in many situations. But my real question is, since I am not an expert: 1. There is something that can be done in P0057R0 that simply cannot be done by resumable expressions + reasonable library support? For me await/async + embedded scheduler is something like getting married to an implementation detail that a run-time must support. The mandatory type-erasure is not nice, compared to being able to generate what you would write by hand, a function object, which is what resumable expressions do. Am I missing anything here? As I say, my knowledge is quite limited in this area. -- --- 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_2199_66584921.1443872478474 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone,

I do not mean to start = a flame here, but I am still wondering why the coroutines from
P0= 057R0 are still being considered.

For what it is w= orth, I find the paper from Christopher Kohlhoff very clarifying, very well=
reasoned, and providing alternatives for all the important use c= ases from P0057R0 with
superior implementations.

I still share the same concerns as before for P0057R0, mainly:

- mandatory type erasure.
- as Christopher = mentions, embedding a scheduler into the language is not a nice thing.
- viral await is also something to be aware of.

<= div>
On top of that, he shows alternatives for implementation= s:

1. Generators (reified and type-erased).
<= div>2. await.



You al= so have yield as an object, which I think can be of advantage in many situa= tions.

But my real question is, since I am not an = expert:

1. There is something that can be done in = P0057R0 that simply cannot be done by resumable expressions + reasonable li= brary support?

For me await/async + embedded sched= uler is something like getting married to an implementation detail that
a run-time must support. The mandatory type-erasure is not nice, com= pared to being able to generate
what you would write by hand, a f= unction object, which is what resumable expressions do.=C2=A0
Am I missing anything here? As I say, my knowledge is quite lim= ited in this area.



--

---
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_2199_66584921.1443872478474-- ------=_Part_2198_465842834.1443872478474-- .