220 21753 article Path: news.gmane.org!not-for-mail From: German Diago 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: Wed, 14 Oct 2015 14:18:49 +0700 Lines: 119 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> <561DD00F.2070306@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c0b865ebedb1305220b5fa1 X-Trace: ger.gmane.org 1444807136 26359 80.91.229.3 (14 Oct 2015 07:18:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 07:18:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKJVOEEVYNRBWUD7CYAKGQE4K5N6HA@isocpp.org Wed Oct 14 09:18:55 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f197.google.com ([209.85.192.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmGKs-0006T7-Ep for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 09:18:54 +0200 Original-Received: by pdbkn3 with SMTP id kn3sf63532792pdb.0 for ; Wed, 14 Oct 2015 00:18:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=+cJcjDJ/McjmwNvnzH+XkqOBj/qDkYUh0pzF0CwVx6w=; b=NEfZSpyabB64npCaY2PuRNPqmOOB6xbS43Nri4iPv47kfEBw3SpfsTHpMKGeMLSpML x1cAPK1t61XgsvFAG7yhKwY7Fe/dwGiGBJbYGP+QzFvqg65arI4oh6crCPmfqMmI7VaK YRiDKvAO43SW1M2+dOl16IzkeZrSYsLCqtOcXhvFkoMSX1QhwlOGQD2JsEnQ/FGspRKI G1bC+FFjUczpaebrx5A4T8FLmj0vCeL6Rnfm5kjXwNZ2Ht+Do8tjEizLLKgmt8Oko8CZ cvKfCh33CZOqHVGNmo3EUtgBXy9DS5hsipwJThKcXqtKz4EIzUhOxwdzsBMRw/wflR2q ldUQ== X-Gm-Message-State: ALoCoQm2lac81bZLtqgHdkc27ZSl4H8Rt94hd45JtnnGZYdZ5BwClrcpuMbsoa5+CwuAvGIRJnjF X-Received: by 10.66.122.201 with SMTP id lu9mr1349086pab.8.1444807133026; Wed, 14 Oct 2015 00:18:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.85.111 with SMTP id m102ls15024qgd.43.gmail; Wed, 14 Oct 2015 00:18:50 -0700 (PDT) X-Received: by 10.129.146.201 with SMTP id j192mr991224ywg.315.1444807130009; Wed, 14 Oct 2015 00:18:50 -0700 (PDT) Original-Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com. [209.85.160.170]) by mx.google.com with ESMTPS id f190si3112402ywe.198.2015.10.14.00.18.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2015 00:18:49 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.160.170 is neither permitted nor denied by best guess record for domain of german.diago@hubblehome.com) client-ip=209.85.160.170; Original-Received: by ykfy204 with SMTP id y204so16707637ykf.1 for ; Wed, 14 Oct 2015 00:18:49 -0700 (PDT) X-Received: by 10.129.153.22 with SMTP id q22mr1048481ywg.328.1444807129869; Wed, 14 Oct 2015 00:18:49 -0700 (PDT) Original-Received: by 10.37.80.72 with HTTP; Wed, 14 Oct 2015 00:18:49 -0700 (PDT) In-Reply-To: <561DD00F.2070306@gmail.com> X-Original-Sender: german.diago@hubblehome.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.160.170 is neither permitted nor denied by best guess record for domain of german.diago@hubblehome.com) smtp.mailfrom=german.diago@hubblehome.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:21753 Archived-At: --94eb2c0b865ebedb1305220b5fa1 Content-Type: text/plain; charset=UTF-8 Not "by hand" - this type-erasure can be within standard library. Just like std::function. And it is not hard at all to use lambdas with std::function, when needed. Completely agree. This is the way it should be done, IMHO. Not embedding it into the language for no gain. > 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 >> > This is due to embedding more into the language. The resumable expressions can do all of it in libraries. So as a solution, I find it superior a library than embedding into the language > 2) less library support code >> > Again, because it is embedded. > 3) less abstraction overhead (see TcpReader, for example) >> >> This is a carefully chosen use-case. There are many others. Though, it is a real one, I cannot say it is not. > 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 need to write less code does not mean that it is zero-overhead, which is a main point of the discussion. -- --- 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/. --94eb2c0b865ebedb1305220b5fa1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Not "by hand" - this type-erasure can be within standard library.= Just like std::function. And it is not hard at all to use lambdas with std= ::function, when needed.

Completely= agree. This is the way it should be done, IMHO. Not embedding it into the = language for no gain.
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,<= br>
P0057 solution will results in:

1) less user written code

This is due to embedding more into the language. The resumable expre= ssions can do all of it in libraries.
So as a solution, I fin= d it superior a library than embedding into the language
=C2=A0
2) less library support code

<= /div>
Again, because it is embedded.
=C2=A0
3) less abstraction overhead (see TcpReader, for example)

This is a carefully chosen use-ca= se. There are many others. Though, it is a real one, I cannot say it is not= ..
=C2=A0
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 need to write less code does not mean that= it is zero-overhead, which is a main point of the discussion.
=C2=A0

--

---
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>.
--94eb2c0b865ebedb1305220b5fa1-- .