`promise_contract_t` currently returns `std::pair<std::promise<T>, std::future<T>>`

[brycelelbach]

• [x] It should return something like std::pair<executor_promise_t<Executor, T>, executor_future_t<Executor, T>>.
• [x] Also, we should probably have a type traits executor_promise_t similar to executor_future_t.

[chriskohlhoff]

If the problem is that it shouldn't be using std::promise/future but something like standard_promise/executor_future_t<Executor, T>, where executor_future_t<Executor,T> is SFINAE-constrained to be one of the concrete Future types defined in the proposal, that's reasonable. However, it doesn't sound right to use unconstrained executor_promise_t/executor_future_t here, because how would the query implementation know how to construct this pair for arbitrary promise and future types?

(Keep in mind the friend query() that is currently specified to return std::pair<std::promise<T>, std::future<T>> is just the default query for executors that don’t implement the query themselves. Executors that do implement it themselves just need to adhere to the requirements documented under the promise_contract_t property.)

BTW, executor_promise_t could probably just be defined in terms of the result of this query, e.g.

template <class Executor, class T>
struct executor_promise
{

  using type = decltype(     execution::query(       std::declval(),       execution::promise_contract_t()).first); };

On Sun, May 6, 2018, at 3:52 PM, Bryce Adelstein Lelbach aka wash wrote:

It should return something like std::pair<executor_promise_t<Executor, T>, executor_future_t<Executor, T>>.

Also, we should probably have a type traits executor_promise_t similar to executor_future_t.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/executors/futures/issues/93

[brycelelbach]

Why force it to be constrained to one of the concrete types in the proposal?

If I'm defining my own executor type that has the promise property and I want to implement my own Promise type, what do I do?

Our intention, I believe, was that executors would be able to make a future promise pair in some executor-specific way and return them.

I do see what you're saying - IIUC, executors can't control how query is defined?

But then how does this work any better when returning a pair of std::future/std::promise?

[LeeHowes]

The std::future/std::promise thing was a leftover from when I was defining this independently of the futures proposal. That should definitely change. It can return a standard_semi_future and it is up to the executor to bind it if necessary. Or it can return a continuable_future, but we would need to template the polymorphic return type typedef then.

Otherwise Chris's changes are fine I think. The free function calls the specific query in the general case. If the specific query is not provided (caught by the check on the future type) then the free friend function works too and provides standard types.

We can reword in terms of the query, but the basic functionality is as expected.

[LeeHowes]

I've landed a basic change here. Unsure whether we should make polymorphic_query_result_type templated on the executor and have it defined in terms of a continuablefuture rather than a semifuture.

@chriskohlhoff any thoughts?

If not we will have to leave this open for V1.5.

[dhollman]

I don't think we can make polymorphic_query_result_type templated on the executor, since the intent is to type-erase the executor.

[LeeHowes]

Hmm. Well for this purpose a semi_future works fine.

[dhollman]

105 Should fix this. @brycelelbach please close if #105 addresses your concerns.