On 26 May 2015 at 13:50, Peter Dimov wrote:
The use case I was wondering above is that you create a promise, but never get a future from it.
The present resumable functions proposal requires a promise to be created on entry to every resumable function. The first time the function is suspended promise.get_future() is called, and the future returned immediately. If the resumable function never suspends, promise.get_future() ought to be called straight after the set_value() OR make_ready_future will be used instead. At least, that will be the case of Gor agrees to tweak the operation ordering in the TS as I have requested (I can't see it being a problem). If that ordering is implemented, then with these future-promises a resumable function which was never suspended has identical runtime overheads to a non-resumable function, and that is a HUGE win over the present situation which is much less efficient. All this assumes I understand the current TS before the committee correctly and its exact boilerplate expansion from the await/yield etc keywords. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/