220 21354 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: Tue, 6 Oct 2015 07:05:11 -0700 (PDT) Lines: 160 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_354_1568678149.1444140311503" X-Trace: ger.gmane.org 1444140317 3952 80.91.229.3 (6 Oct 2015 14:05:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Oct 2015 14:05:17 +0000 (UTC) Cc: german.diago@hubblehome.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBGFKZ6YAKGQEO4BW3NQ@isocpp.org Tue Oct 06 16:05:16 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZjSrh-0007SD-Kr for gclcip-std-proposals@m.gmane.org; Tue, 06 Oct 2015 16:05:13 +0200 Original-Received: by obclh8 with SMTP id lh8sf24790583obc.2 for ; Tue, 06 Oct 2015 07:05:12 -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=AGpprbSnNnTOkdKre8E6NWNOwDfeLFBuSr1aaf7SP+c=; b=HpPAD5971jWhYghLHyk7lF49ynSu2oAzzWrMWzcfPruZKo+59gc0Gm1Ko4g0QmOmYu xh5GCrFWMrt+79Q/9EBMtlfHBarM2T6pyuG4yTujDzi3QwMS4rZ5UDlOTwkd6haGFRlO y7vJJfX37jbZULZNCB6FFdOe7CQaRZ5p7glafJ2CPnBSZX2D8alw2wY0y3YuNs/XrUAH YTHk/BkjMuVevMj59Vcp8fQo5KXiR1QvC4D7hxxMAgw1PZjh64k6pcK40oWq3Tf4hV1O +hqeh3coNL4ahSPTVoVMr3Dde1QBfdTwH6PMy0wy/Ryv05ARoCXLNbcgxyj9IixNYWfD RbEw== 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=AGpprbSnNnTOkdKre8E6NWNOwDfeLFBuSr1aaf7SP+c=; b=RdO/yvjBxKdCgkA/V1dBnHez1dEJu1OXfbgGVCuS37EdDGpVDQTXukijjUWZjI3zE3 S2pjzsge05GORpjjR+2vG4t9LcArFZyCK0g3NWGI3PgTv+zKdcwLtl9ty81NhU5VKcCx 2d9a85u2tmc4cAlkLDWe5ulRxODOzc9k30np4BmdwWS3avz3PO3hQBjjwwDXcgyf/d/C ZX0FXemVS6869mIL6bplKhAYT7ShpqZDlCBEKZWZwyfkoKJS5/2awamtHRL/2cZketQN gtFqs6/V8+HWI9v4C2lUtkdVzQc0LIBgkFs/CbHJtXxuNNZzTCeKz7l/Oficu7q7bkVH hjvA== X-Gm-Message-State: ALoCoQleN/lVbSWPjmry7YVJqECRbo400/u0ZLDzDcyfccpALRWNwLYbbhfTdas6Q8tnEzygBLxc X-Received: by 10.182.117.225 with SMTP id kh1mr30594009obb.12.1444140312892; Tue, 06 Oct 2015 07:05:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.131.21 with SMTP id f21ls311130iod.24.gmail; Tue, 06 Oct 2015 07:05:12 -0700 (PDT) X-Received: by 10.50.43.195 with SMTP id y3mr57910igl.1.1444140312009; Tue, 06 Oct 2015 07:05:12 -0700 (PDT) In-Reply-To: <9e17f8a6-4f5b-47dd-9f76-a4675a5ede3c@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:21354 Archived-At: ------=_Part_354_1568678149.1444140311503 Content-Type: multipart/alternative; boundary="----=_Part_355_1209397268.1444140311504" ------=_Part_355_1209397268.1444140311504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, October 6, 2015 at 7:34:03 AM UTC-4, Germ=C3=A1n Diago wrote: > > How much more performant? Is it enough to be worth arguing about? After= =20 >> all, most things you'll be using await for won't be cheap operations. Wi= ll=20 >> you actually *notice* any such performance loss? >> > > Well this is a usual argument to use "productivity languages". As far as = I=20 > know, the definition of performance for C++ is that between C++ and machi= ne=20 > code, we can only choose assembly. > Yeah, tell that to iostream. While that might be a goal of C++, it's not an *overriding* goal. It=20 doesn't automatically pre-empt all other considerations. So far, it has been good to me. Boxing is bad, bad, bad. > Why? I do not think it is a good idea in a language abstraction. About the=20 > scheduling, not sure, but I believe what you say for now :). > =20 > =20 > >> When a resumable function is used in a resumable expression, the=20 >> definition of the function must appear before the end of the translation= =20 >> unit. >> > > There is an example of a boxed generator with separate compilation in the= =20 > paper. Doesn't that contradict whay you are claiming? > So let me get this straight. A resumable function, under this design, is inline. However, by making my= =20 function *not* resumable, I can get the effect of a non-inline resumable=20 function by making the function body actually a lambda (which the compiler= =20 will deduce is a resumable function), and returning it in some object. And= =20 if I have allocation needs, I have to explicitly specify them in the body= =20 of every function that has those needs. And so forth. Meaning that, in a rather common case, the user has to do a lot of work.=20 Isn't the whole point of a compiler to do that sort of gruntwork *for you*?= =20 Why not make `resumable` do this "boxing" work for you, and have `inline=20 resumable` do what the current thing suggests? After all, the current=20 `resumable` implies `inline`, so we'd just be making it explicit. So `inline resumable` means to do what it currently says. And `resumable`= =20 means to automatically do boxing and so forth. Or if you prefer `resumable`= =20 to mean the current case, introduce another keyword to have the compiler=20 generate the "boxing" code for you. Users should not have to do this nonsense manually, especially considering= =20 how common such code will be. --=20 ---=20 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 e= mail 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-proposa= ls/. ------=_Part_355_1209397268.1444140311504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, October 6, 2015 at 7:34:03 AM UTC-4, Germ=C3= =A1n Diago wrote:
How much more performant? = Is it enough to be worth arguing about? After all, most things you'll b= e using await for won't be cheap operations. Will you actually notic= e any such performance loss?

Well this i= s a usual argument to use "productivity languages". As far as I k= now, the definition of performance for C++ is that between C++ and machine = code, we can only choose assembly.

Yea= h, tell that to iostream.

While that might be a goal of C++, it'= s not an overriding goal. It doesn't automatically pre-empt all = other considerations.

So far, it has been good to me. Boxing is bad, = bad, bad.

Why?

I do not think it is a= good idea in a language abstraction. About the scheduling, not sure, but I= believe what you say for now :).
=C2=A0
=C2=A0
When a resumable function is used i= n a resumable expression, the definition of the function must appear before= the end of the translation unit.

There is a= n example of a boxed generator with separate compilation in the paper. Does= n't that contradict whay you are claiming?
=

So let me get this straight.

A resumable function, un= der this design, is inline. However, by making my function not resum= able, I can get the effect of a non-inline resumable function by making the= function body actually a lambda (which the compiler will deduce is a resum= able function), and returning it in some object. And if I have allocation n= eeds, I have to explicitly specify them in the body of every function that = has those needs. And so forth.

Meaning that, in a rather common case= , the user has to do a lot of work. Isn't the whole point of a compiler= to do that sort of gruntwork for you? Why not make `resumable` do t= his "boxing" work for you, and have `inline resumable` do what th= e current thing suggests? After all, the current `resumable` implies `inlin= e`, so we'd just be making it explicit.

So `inline resumable` me= ans to do what it currently says. And `resumable` means to automatically do= boxing and so forth. Or if you prefer `resumable` to mean the current case= , introduce another keyword to have the compiler generate the "boxing&= quot; code for you.

Users should not have to do this nonsense manual= ly, especially considering how common such code will be.

--

---
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_355_1209397268.1444140311504-- ------=_Part_354_1568678149.1444140311503-- .