220 14030 <15c7ed1d-55c5-4329-9ada-605ee4c27080@isocpp.org> article Path: news.gmane.org!not-for-mail From: chris.kohlhoff@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Comment on N4244 Date: Sat, 18 Oct 2014 15:36:16 -0700 (PDT) Lines: 128 Approved: news@gmane.org Message-ID: <15c7ed1d-55c5-4329-9ada-605ee4c27080@isocpp.org> References: <0632b234-2e7b-489f-a640-aa927648eaf7@isocpp.org> <02d9673d-3dd3-4fec-aa7a-b925b73f9893@isocpp.org> <6d5e0622-29bb-4196-ad7b-9c6b5f08f8cb@isocpp.org> <75c80e2f-e1a1-4e5f-8ae3-10ba25baad64@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69_534237030.1413671777121" X-Trace: ger.gmane.org 1413671788 23651 80.91.229.3 (18 Oct 2014 22:36:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Oct 2014 22:36:28 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCS7VEH374ORBY6WRORAKGQEHHTFZYI@isocpp.org Sun Oct 19 00:36:22 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xfcbl-00042r-6f for gclcip-std-proposals@m.gmane.org; Sun, 19 Oct 2014 00:36:21 +0200 Original-Received: by mail-pa0-f69.google.com with SMTP id lf10sf18593175pab.0 for ; Sat, 18 Oct 2014 15:36:20 -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 :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=j5OJkmsci6LBH+ZOs24xvtMXCXBNEPqm3Q2e9qrHKLw=; b=ULQEV8IRS6xxZqUzi4+2BnWSTJRIE2SH9kjkR3egpfQBK54DujsSm2ZNFk/K4iBzwG xYdH72uxHigiP/Fd70gwjYyqq7OAhYRAf6p7NKN2cU55nZ+KjsDjnNNi11Tjn5oM9b+U vucXd3E7b6OyWprqt73yoHv4aov785Dc4LPMQqb/6e59i3AuhvAQvLpBLZvszr200K1a xJaowQTqCKM9/D7RV8MEUPOxRdZAI5tSFPdO9KQYEpU9mcvn8ctUV2JNv1/f3YTZqIaR Zmet3K8hudsvedUyrrt/tA0ChkRiYO/PzL+SrEbjD3k9ta+vNLOs7WbJdiK3T/9f4T5d NUBg== 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:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=j5OJkmsci6LBH+ZOs24xvtMXCXBNEPqm3Q2e9qrHKLw=; b=cp6w3vI1cXZy3ZKEOquHGA5Kn39RFQywMRTp2VTySZd1xLEPHdxWgowQEx4WL5brzK 6DKXawdO5/Lz58p2lSnk7AkRmyPV5PMp6fBO1E0m/horgKnNn1VM3XMTt8gcRkWDlWGc oAmposj0595KZs8huJ+Au3C/Z8Or/fKcSKsErSaFGuRJeCcFluX0NIZtSfl3OjGTlHVM yuLBptZnwcTmRUaKhpV8AYPD81bTlkm2ebFzlmZBCct7fCrF3Uq+KpnNxV/PfMxiU2v/ EZLQ01PVO8trxOntpyyIGiTVDkKbHC4OAERDfPgv1ddJXz2sic/H+q9VJqrx6mXeM+n+ JBqA== X-Gm-Message-State: ALoCoQluk5TcVOF6aOEsbWr4Bdt0iCCnvQnImEQqToBaT9PUqgo6gw5QuFvvpHx1DyFBDI0EZ3hv X-Received: by 10.66.182.131 with SMTP id ee3mr12157121pac.4.1413671780010; Sat, 18 Oct 2014 15:36:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.254.165 with SMTP id aj5ls301128igd.6.gmail; Sat, 18 Oct 2014 15:36:19 -0700 (PDT) X-Received: by 10.50.98.39 with SMTP id ef7mr80901igb.0.1413671779424; Sat, 18 Oct 2014 15:36:19 -0700 (PDT) In-Reply-To: X-Original-Sender: chris.kohlhoff@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:14030 Archived-At: ------=_Part_69_534237030.1413671777121 Content-Type: text/plain; charset=UTF-8 Hi Ville, On Saturday, October 18, 2014 11:41:55 PM UTC+11, Ville Voutilainen wrote: > > On 18 October 2014 15:23, > wrote: > > Ville, > > > > Have you seen N4134? Fully open. Not tied to the future or any > particular > > abstraction. > > As far as I understood it, the generators/futures/whichever-things the > resumable > function of N4134 returns must be shared-semantics types that share > state with the > resumable function itself. Chris's proposal seems to be so that the state > is completely within the lambda, and thus the lambda itself can just > return > an int if it so wants to. > > Then again, I don't quite see how to return a future with N4244 - I > would > expect I need to return a future& and have the future as a capture. > It's a similar principle to when you write "async(f)". The function f doesn't return the future; instead std::async wraps it in the necessary machinery to run f and make the result available as a future. So, we could have: std::future result = run_resumable([]() resumable { ...; return 42; }); If you want to write this as a function to enable separate compilation, then it's: std::future my_resumable_function() { return run_resumable([]() resumable { ...; return 42; }); } You could possibly even do: auto f = []() resumable { ...; return 42; }; std::future result = run_resumable(std::ref(f)); to produce a future from a resumable lambda stored at a location of your choosing. Cheers, Chris -- --- 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_69_534237030.1413671777121 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ville,

On Saturday, October 18, 2014 11:41:55 PM= UTC+11, Ville Voutilainen wrote:
On 18 October 2014 15:23,  <gorni...@gmail.com> wrote:
> Ville,
>
> Have you seen N4134? Fully open. Not tied to the future or any par= ticular
> abstraction.

As far as I understood it, the generators/futures/whichever-things= the resumable
function of N4134 returns must be shared-semantics types that share
state with the
resumable function itself. Chris's proposal seems to be so that the sta= te
is completely within the lambda, and thus the lambda itself can just re= turn
an int if it so wants to.

Then again, I don't quite see how to return a future<T> with N424= 4 - I would
expect I need to return a future<T>& and have the future as a= capture.

It's a similar principle to when you w= rite "async(f)". The function f doesn't return the future; instead std::asy= nc wraps it in the necessary machinery to run f and make the result availab= le as a future. So, we could have:

  std::fut= ure<int> result =3D run_resumable([]() resumable { ...; return 42; })= ;

If you want to write this as a function to enabl= e separate compilation, then it's:

  std::fut= ure<int> my_resumable_function()
  {
  =   return run_resumable([]() resumable { ...; return 42; });
=   }

You could possibly even do:
  auto f =3D []() resumable { ...; return 42; };
  std::future<int> result =3D run_resumable(std::ref(f));
=

to produce a future from a resumable lambda stored at a= location of your choosing.

Cheers,
Chri= s

--

---
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_69_534237030.1413671777121-- .