220 21738 article Path: news.gmane.org!not-for-mail From: Gor Nishanov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: is await an extension of the do-notation? (was Re: Re: Resumable expressions p0114r0 vs async/await P0057R0) Date: Tue, 13 Oct 2015 19:31:33 -0700 (PDT) Lines: 98 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> <56114953.4030701@wanadoo.fr> <561B403D.4030403@gmail.com> <561C07D1.3080304@gmail.com> <561C213F.1060009@gmail.com> <561C3875.2050701@gmail.com> <86924069-44d0-447f-bf8a-a42e46579832@isocpp.org> <561D79A7.8080007@gmail.com> <894616d6-9609-4038-b2bc-d2c62df21e0f@isocpp.org> <99bdb3ae-9214-4440-8572-4c47a61eda46@isocpp.org> <78f1c83a-f866-4f64-aba2-939078fdc58b@isocpp.org> <561DA103.3040902@gmail.com> <3ec60032-9390-4606-8a32-870a57163fc3@isocpp.org> <561DBB7C.80403@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_225_539591925.1444789894099" X-Trace: ger.gmane.org 1444789897 10557 80.91.229.3 (14 Oct 2015 02:31:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 02:31:37 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC47RF4IW4GRBB7562YAKGQEAPHOH6Y@isocpp.org Wed Oct 14 04:31:37 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f199.google.com ([209.85.213.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmBqq-0000I6-Up for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 04:31:37 +0200 Original-Received: by igcsm6 with SMTP id sm6sf65902812igc.2 for ; Tue, 13 Oct 2015 19:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to: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=kUc9wqRxgT7+P6pq1zssc07CcO7cd0JcGf3ouY88XwE=; b=dXEHOP+Vi+LI3xlEMNOfdikGn0eyeAjGLXNGVym+w1dHSP3MS0n6LFoFonAzJIbcqx fVauAHHky8xOrimAwHMVt6EKSX/jJen6hQCkIGd8gdG+4H5y7cD5BdZAE2EzD4JGrs3n pzIymXPW7jhgMONDh+LSIXMw1oQi3Cyj10ZZvovcf9o5XlAv58ok6v/5Pz/+MX1MJuYv mEfqEtvU4Sz3MhcXn1j1G3ayw3A5EzhN+x0CavIJRRDuqY+ukkbgfxTDnB0+USafxI+s LA6Jn74o3AkyHv4IPizOYMxjTsRJm7e8MNEnOST+MYzqBWXM6fDQlTJ8VGBsYL84qvo+ hvHg== 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: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=kUc9wqRxgT7+P6pq1zssc07CcO7cd0JcGf3ouY88XwE=; b=JPy/tHD2+hZr69JAwu1NABc44FtYTC3D5psaiU6YSw7IDTRA9vQ7Ytw9K9HM2/JLIa a0jI0iCy8KA+noO69iUZJMRKoRyC9no81Y+HHAulx520UAwDsjAl6wYvrzx3YokTrwu4 vzM+qGhWFlNbVq5c8sh1dkCcQSNbyQ7n1E4Sfo8TrlyQYNztF0r3eh1FIrYGljhThBgU sQL3bh4mFo/8Z8M0w3vWQEz/T+AxzmPAZFr872+cAIK7L+hXiWi3/o5k/ORL6bWdJoCm 2zccNIdEBeHImroFZ/8IwXEQhm9v+2LeJRM5PgrV2OqXVEDAL0lbO8AJ5V9pcxQ1QaQr EoAQ== X-Gm-Message-State: ALoCoQlW5aH0T8mt+aOUop+wkUODMjQXIW4a7HD5ptp9l9jiWKYKvxwBb6tsRNdYgxpn2lg78n5R X-Received: by 10.50.30.37 with SMTP id p5mr1074094igh.11.1444789896009; Tue, 13 Oct 2015 19:31:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.129.7 with SMTP id c7ls44067iod.15.gmail; Tue, 13 Oct 2015 19:31:34 -0700 (PDT) X-Received: by 10.50.164.165 with SMTP id yr5mr15892igb.12.1444789894915; Tue, 13 Oct 2015 19:31:34 -0700 (PDT) In-Reply-To: <561DBB7C.80403@gmail.com> X-Original-Sender: GorNishanov@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:21738 Archived-At: ------=_Part_225_539591925.1444789894099 Content-Type: multipart/alternative; boundary="----=_Part_226_1357669275.1444789894100" ------=_Part_226_1357669275.1444789894100 Content-Type: text/plain; charset=UTF-8 On Tuesday, October 13, 2015 at 7:18:44 PM UTC-7, Evgeny Panasyuk wrote: > > > It does not erase type: > It forces you to do it by hand, as you can see this in both generator and async examples. The key is it requires stationary frame and for that you either need to heap allocate or keep the lifetime of the coroutine fully enclosed in the lifetime of its consumer. Exactly the same case where heap elision is done. > But, even if there would be no copyability/moveability, and as the > result we cannot use std::vector - we still can place N coroutines into > array with single allocation: make_unique(N) > P0057 allows you to customize allocation, thus you can achieve the same goal, but with different means. I do not claim that feature lists are identical for P0057 and P0114. I claim that for a complicated problem, like async programming, for example, P0057 solution will results in: 1) less user written code 2) less library support code 3) less abstraction overhead (see TcpReader, for example) Than a solution to the same problem in P0114. If you want to argue superiority of P0114, pick a problem (hint, hint async programming) write a solution, compare with equivalent of P0057. -- --- 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_226_1357669275.1444789894100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, October 13, 2015 at 7:18:44 PM UTC-7, Evge= ny Panasyuk wrote:

It does = not erase type:

It forces you to do it by hand, as you= can see this in both generator and async examples. The key is it requires = stationary frame and for that you either need to heap allocate or keep the = lifetime of the coroutine fully enclosed in the lifetime of its consumer. E= xactly the same case where heap elision is done.
=C2=A0
But, even if there would be no cop= yability/moveability, and as the=20
result we cannot use std::vector - we still can place N coroutines into= =20
array with single allocation: make_unique<coroutine[]>(N)

P0057 allows you to customize allocati= on, thus you can achieve the same goal, but with different means.
I do not claim that feature lists are identical for P0057 and P0114. I cla= im that for a complicated problem, like async programming, for example,

P0057 solution will results in:

<= div>1) less user written code
2) less library support code
<= div>3) less abstraction overhead (see TcpReader, for example)
Than a solution to the same problem in P0114.
If you = want to argue superiority of P0114, pick a problem (hint, hint async progra= mming) write a solution, compare with equivalent of P0057.

--

---
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_226_1357669275.1444789894100-- ------=_Part_225_539591925.1444789894099-- .