220 21750 <561DEFFD.2010802@gmail.com> article Path: news.gmane.org!not-for-mail From: Evgeny Panasyuk 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 09:02:37 +0300 Lines: 38 Approved: news@gmane.org Message-ID: <561DEFFD.2010802@gmail.com> 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> <58628096-14ae-42b2-89d3-c0bd2183bbc0@isocpp.org> <561DC957.8080603@gmail.com> <510ce172-976a-4e3a-ae68-31fdb40af4d7@isocpp.org> <9dd3f28c-4ffb-4e08-9955-242c46e14527@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed X-Trace: ger.gmane.org 1444802577 24029 80.91.229.3 (14 Oct 2015 06:02:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 06:02:57 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC54TLGKR4LBBA7A66YAKGQEDIQ6HQI@isocpp.org Wed Oct 14 08:02:45 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f200.google.com ([209.85.217.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmF9B-0005Gx-EV for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 08:02:45 +0200 Original-Received: by lbwr8 with SMTP id r8sf20093468lbw.0 for ; Tue, 13 Oct 2015 23:02:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-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=S/Y+lhmbXmQj+xVqzjaKZVBcctIQuSc0TX+ygHmN9X4=; b=QA1cepc8cNn/BLNRkoRsgskZb5u2cUsolpO9YnWD2UZWC+3zCNru5dlolEiZzmszAh 9Z6CqXJ/CIHT71Yxq2CiympLO5DQGVvWFrSNVOcOjMxS2YsWLOyBi/fpdkytO6iyi6nm EacurxKZ3OEnc9cW4z7ZEmlyalgTjTdQHxTQyEdY7YmPHDHW7STAiI7SrNSbX4NWHVQe JmLXD4oU9dsi/ZYN8XaROQk7iPf0lcbxX4kvwTth/N38fZcscdNjvkSKAJxsiTEIM9Zf 7u1fim3IDA1rm6AZ1MZwAfMMBnf89i8ivsGF5l4tXlX+7asqkRINIvgL0cNGs5/WKtdg 1zmw= X-Gm-Message-State: ALoCoQkGou6HYFFpX7tNSBJvlwY1OzXUzNKSlpK8nN0RJ3CZX0dwu+Y9Nxe25/iY18uGAen372Q4 X-Received: by 10.112.142.195 with SMTP id ry3mr301449lbb.22.1444802564629; Tue, 13 Oct 2015 23:02:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.25.67 with SMTP id 64ls752030lfz.41.gmail; Tue, 13 Oct 2015 23:02:43 -0700 (PDT) X-Received: by 10.112.32.72 with SMTP id g8mr586774lbi.22.1444802563329; Tue, 13 Oct 2015 23:02:43 -0700 (PDT) Original-Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com. [2a00:1450:4010:c07::22b]) by mx.google.com with ESMTPS id rm8si4525977lbb.16.2015.10.13.23.02.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2015 23:02:43 -0700 (PDT) Received-SPF: pass (google.com: domain of evgeny.panasyuk@gmail.com designates 2a00:1450:4010:c07::22b as permitted sender) client-ip=2a00:1450:4010:c07::22b; Original-Received: by lffv3 with SMTP id v3so6195346lff.0 for ; Tue, 13 Oct 2015 23:02:43 -0700 (PDT) X-Received: by 10.25.20.167 with SMTP id 39mr396794lfu.28.1444802562838; Tue, 13 Oct 2015 23:02:42 -0700 (PDT) Original-Received: from [192.168.0.186] (81.13.117.87.donpac.ru. [87.117.13.81]) by smtp.googlemail.com with ESMTPSA id k19sm1073307lfg.8.2015.10.13.23.02.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2015 23:02:42 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: X-Original-Sender: Evgeny.Panasyuk@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of evgeny.panasyuk@gmail.com designates 2a00:1450:4010:c07::22b as permitted sender) smtp.mailfrom=evgeny.panasyuk@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:21750 Archived-At: 14.10.2015 8:36, Ville Voutilainen: > On 14 October 2015 at 07:14, Evgeny Panasyuk wrote: >>> The starting point of my design was a lambda* with the properties you >>> describe. When applied to problems I needed solving I found it >>> unsatisfactory and therefore went with N4134 proposal. That does not mean >>> that at some point, somebody won't be able to invent a better lambda* and >>> get it standardized. >> Well, this is also the problem. If we already would have some stackless >> coroutines in ISO - it would be much harder to get additional one into it. > > That "much harder" is fairly questionable. While there apparently are people > who think working on e.g. stackful coroutines becomes a pointless exercise > if Gor's proposal is accepted, and while there are people who prefer > picking one rather than many solutions (albeit the problems being different), Indeed, there is overlap between use cases of stackless and stackful coroutines. But in addition, each one has it's own area where it beats another approach. And I think C++ ISO needs both - stackless and stackful coroutines. (though I would prefer to get stackless into ISO first, because stackful can be completely implemented in library, like Boost.Context/Coroutine) But here is another situation - both options aim to exactly same use cases, and even one is strictly more powerful than another. If we would have stackless coroutine with concrete type - then we always can implement type-erasure on top of it. Just like we have std::function type-erasure for concrete lambda types. -- --- 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/. .