220 21389 <9838dc2a-6f1b-4dca-b4b9-72b6a9917c38@isocpp.org> 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 18:48:06 -0700 (PDT) Lines: 187 Approved: news@gmane.org Message-ID: <9838dc2a-6f1b-4dca-b4b9-72b6a9917c38@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5649_1756200278.1444182486942" X-Trace: ger.gmane.org 1444182491 31889 80.91.229.3 (7 Oct 2015 01:48:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Oct 2015 01:48:11 +0000 (UTC) Cc: german.diago@hubblehome.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBWHT2GYAKGQET2C5WGA@isocpp.org Wed Oct 07 03:48:10 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f198.google.com ([209.85.160.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zjdpx-0000Xv-UH for gclcip-std-proposals@m.gmane.org; Wed, 07 Oct 2015 03:48:10 +0200 Original-Received: by ykdz138 with SMTP id z138sf5938301ykd.3 for ; Tue, 06 Oct 2015 18:48:09 -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=0xAU1FUD7XaT+y/IRmQfMZ+KvY66WydTQ8+WKQ+unV8=; b=OBvMcZVDNBIZeFoZR0Si10enC6N41iEu09x6llwK9hYvPjN9k3HkDNzKDbbtP2kpDK NmzGeYBgpeQGXCLejxXcmmblqTPs+AeV1oahuQJGYs3VCZutWwq46lare22WGz2rB3IQ u99SB+dgiaJiDZftKYcZ87kr5/Qugou4FrryRMdJB5EH3pUOeygAvZWmqwTcYmbtzynZ rnfTp/EgyAxpx6eRAO8YPb8nfpcrgS7wR+iVDYYl8D2+pxvMy7k7pUNYNHJ4S6S1XjJ1 p3nGP3HzvPStqU8+Vh/Auibo6XOInIpUUJ5283r703wx6xqRpdUSeBNpTpwwTBGaNwi3 T50Q== 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=0xAU1FUD7XaT+y/IRmQfMZ+KvY66WydTQ8+WKQ+unV8=; b=M5ZWBhOCliKDU+5gKPCURAmFHBe6eeoFurCja/cR1UCpevCWLhfyBIS9hl1XfiXRBF wRdG95Bh0mEQrSN3CCdrEKVfGOFBMToLmHteAGaBXFXQpSbu1r7OTlPTO1m3oeKISCNY c1NabFkLFvi7cLo/7MeGQ2jrWse/6W/tDrvfs/K+QA7cDclEMAg6SKsNEzS7RNyQUR86 eWkuqKFjLaWNmxPhz48zm74A9KMn2bP9muYsDKzoVoSg54ofEqHPwMQjqhuKkbYqZfT+ 8uiSbadkmh3BwxjP129IUlemEZaJlSY26lZUUzxXLzq/JCa5HuPRXlgHwVCZVR9XKGAe YN4A== X-Gm-Message-State: ALoCoQlkvWACvYswH/2agsWET1gncrIw5+u9M6JQllvML4emaojPhV0yVOIba0NlDFBZQJ3swI0l X-Received: by 10.129.78.205 with SMTP id c196mr19987241ywb.21.1444182489047; Tue, 06 Oct 2015 18:48:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.133.133 with SMTP id p5ls63314ioi.78.gmail; Tue, 06 Oct 2015 18:48:08 -0700 (PDT) X-Received: by 10.50.142.9 with SMTP id rs9mr173996igb.16.1444182488152; Tue, 06 Oct 2015 18:48:08 -0700 (PDT) In-Reply-To: <1105ae90-7e2b-49be-b88e-84493c9a1810@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:21389 Archived-At: ------=_Part_5649_1756200278.1444182486942 Content-Type: multipart/alternative; boundary="----=_Part_5650_79037013.1444182486942" ------=_Part_5650_79037013.1444182486942 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, October 6, 2015 at 1:32:31 PM UTC-4, Germ=C3=A1n Diago wrote: > > Why not make `resumable` do this "boxing" work for you, and have `inline= =20 >> resumable` do what the current thing suggests?=20 >> > > Because you can provide library solutions for the boxing in the=20 > proposals, without embedding mandatory boxing into the feature.=20 > Just provide a generator and you are done. Nothing prevents you from= =20 > giving these library types, that can box, but > it does not *force* you from the beginning. > Perhaps you misunderstood what I meant when I was talking about "boxing". I'm not talking about `generator`. I'm talking about the lambda wrapper= =20 part, with optional allocator and whatnot. Having to write `return=20 [=3D](){};` around every resumable function I write is a= =20 pain that I would rather not have to deal with. There is absolutely no reason why that boilerplate can't be written by the= =20 compiler. I cannot see how resumable expressions are worse than await when: > "Worse" is ultimately a matter of opinion. Some restrictions will be=20 considered worse by some people than others. However, I have to say that Gor Nishanov seems to be winning the argument= =20 here, since P0057 is being implemented *efficiently*, with all the inlining= =20 and other simplifications that you claimed was not possible. That was your= =20 biggest argument against resumable functions, and it turned out to be wrong= =20 in at least some of the cases. You can try to dismiss the fact that a good= =20 optimizer made the code equivalent if you like, but that doesn't change the= =20 fact that optimizer aren't getting worse over time. They're getting *better= * .. If there is no objective performance difference between them, then most of= =20 your case just evaporated. So the only remaining function difference is=20 that P0114 requires explicit "boxing" if your code needs boxing. If you're going to bring up having to use `await` frequently: 3. no viral await when refactoring. You say that as though resumable expressions don't have their viral aspects= =20 too. You can only call a resumable function as part of a resumable context:= =20 either the calling function is resumable or the expression making that call= =20 is resumable. Both of these require explicit annotation (except in those=20 cases where the compiler magically works it out for you... somehow). Oh sure, you won't be using `resumable` like you would `await`, or quite as= =20 much. But the fact is, you can't call a `resumable` function unless you've= =20 typed `resumable` somewhere nearby. So you still have to annotate up your= =20 call graph. And you still can't call coroutines of either kind without some= =20 kind of annotation. So I'm not seeing how that's a point in resumable expression's favor. Oh, and I have to agree with P0054: I think I'd rather see awaiting and=20 yielding happen than for them to be implicit. Also, I seem to recall that= =20 an explicit `await` was something that the `expected` guys wanted to be=20 able to key off of. So there is the power to be able to use the=20 functionality for other uses. --=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_5650_79037013.1444182486942 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tuesday, October 6, 2015 at 1:32:31 PM UTC-4, G= erm=C3=A1n Diago wrote:
Why not = make `resumable` do this "boxing" work for you, and have `inline = resumable` do what the current thing suggests?=C2=A0
=

Because you can provide library solutions =C2=A0for the= boxing in the proposals, without embedding mandatory boxing into the featu= re.=C2=A0
Just provide a generator<int> and you are done. N= othing prevents you from giving these library types, that can box, but
it does not *force* you from the beginning.
<= div>
Perhaps you misunderstood what I meant when I was talking about &qu= ot;boxing".

I'm not talking about `generator<T>`. I&#= 39;m talking about the lambda wrapper part, with optional allocator and wha= tnot. Having to write `return [=3D](){<actual function>};` around eve= ry resumable function I write is a pain that I would rather not have to dea= l with.

There is absolutely no reason why that boilerplate can't= be written by the compiler.

I cannot see how resumable exp= ressions are worse than await when:

"= Worse" is ultimately a matter of opinion. Some restrictions will be co= nsidered worse by some people than others.

However, I have to say th= at Gor Nishanov seems to be winning the argument here, since P0057 is being= implemented efficiently, with all the inlining and other simplifica= tions that you claimed was not possible. That was your biggest argument aga= inst resumable functions, and it turned out to be wrong in at least some of= the cases. You can try to dismiss the fact that a good optimizer made the = code equivalent if you like, but that doesn't change the fact that opti= mizer aren't getting worse over time. They're getting better= ..

If there is no objective performance difference between them, then= most of your case just evaporated. So the only remaining function differen= ce is that P0114 requires explicit "boxing" if your code needs bo= xing.

If you're going to bring up having to use `await` frequent= ly:

= 3. no viral await when refactoring.

You say that as th= ough resumable expressions don't have their viral aspects too. You can = only call a resumable function as part of a resumable context: either the c= alling function is resumable or the expression making that call is resumabl= e. Both of these require explicit annotation (except in those cases where t= he compiler magically works it out for you... somehow).

Oh sure, you= won't be using `resumable` like you would `await`, or quite as much. B= ut the fact is, you can't call a `resumable` function unless you've= typed `resumable` somewhere nearby. So you still have to annotate up your = call graph. And you still can't call coroutines of either kind without = some kind of annotation.

So I'm not seeing how that's a poin= t in resumable expression's favor.

Oh, and I have to agree with = P0054: I think I'd rather see awaiting and yielding happen than for the= m to be implicit. Also, I seem to recall that an explicit `await` was somet= hing that the `expected` guys wanted to be able to key off of. So there is = the power to be able to use the functionality for other uses.

--

---
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_5650_79037013.1444182486942-- ------=_Part_5649_1756200278.1444182486942-- .