Home » Blog » 2013 » March » New paper: N3564, Resumable Functions -- Niklas Gustafsson et al.

New paper: N3564, Resumable Functions -- Niklas Gustafsson et al.

By Blog Staff | Mar 15, 2013 04:44 PM | Tags: None

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3564

Date: 2013-02-15

Resumable Functions

by Niklas Gustafsson, Deon Brewis, Herb Sutter, Sana Mithani

Excerpt:

While presenting a proposal that can be adopted or rejected in isolation, this document is related to N3558. The reader is advised to read both as a unit and to consider how the two build on each other for synergy. Reading them in their assigned numeric order is strongly advised.

Add a Comment

Comments are closed.

Comments (3)

1 0

mmocny said on Mar 17, 2013 08:06 PM:

I think it will take a while to truly grok this proposal. I first started thinking about this after seeing the C# presentation from 2012 Lang.next talk on async. I was blown away, but am still considering the implications.

Quick question: if we are tagging functions with resumble keyword, do we need to explicitly return a future wrapper type? If I understand the proposal correct, the return statement can already say return blah; without without the use of make_ready_future.. so its already doing magic, right?
0 0

StephenCleary said on Jun 2, 2013 09:54 AM:

@mmocny:

I'm interested in this proposal, as a former heavy C++ user turned C# user. With async/await, Microsoft has (for the first time AFAIK) introduced a language feature that is both original and useful. Incredibly useful. I fully expect other languages to copy Microsoft's in this regard over the next decade.

I have a blog post (http://blog.stephencleary.com/2011/09/async-ctp-why-do-keywords-work-that-way.html) that discusses the reasons behind async/await as they were added to C# (including the "infer the return type" question). N3564 takes a very similar approach.
0 0

Kjell Schubert said on Nov 7, 2014 09:44 PM:

Both Python and JavaScript started supporting async/await equivalents in recent years (e.g. see https://docs.python.org/3/library/asyncio-task.html and https://www.npmjs.org/package/co). Both languages build their async/await support on top of generator abstractions, with their respective async/await implementations around coroutines yielding future<T> and consuming T. So I wish this standard proposal here would not only address async/await, but also considered (or built on top of) C++ generator/coroutine abstractions (similar to Python 'yield' and 'yield from' expressions).