executors / futures

A proposal for a futures programming model for ISO C++
22 stars 7 forks source link

`make_promise_contract` instead of executor property queries in the wording #117

Open brycelelbach opened 6 years ago

brycelelbach commented 6 years ago

It may make things more readable.

dhollman commented 6 years ago

Do you mean make_promise_contract()?

brycelelbach commented 6 years ago

Yes.

brycelelbach commented 6 years ago

@LeeHowes is this alright?

LeeHowes commented 6 years ago

I don't think it hurts.

LeeHowes commented 6 years ago

Ok, I've been looking into this and I'm not convinced.

We do not currently have a make_cancellable_promise_contract free function. We could - but given the additional complexity of defining the cancellation callback I'm not sure there is value to it. Inside futures code I don't think the free function is very valuable anyway. If we don't have the cancellable contract function, then we need the query anyway as an option for the cancellable form in the text.

In fact, we might want to go the other way and change the precondition of via to define in terms of the query, unless we are assuming that the non-cancellable query is always well-formed if the cancellable one is, in which case the precondition as it is is fine.

LeeHowes commented 6 years ago

PR 123 changes preconditions to be in terms of both queries as an example. If we can assume that only one of those queries is necessary then we can stick with just the non-cancellable version, but for consistency if we are not adding make_cancellable_promise_contract I think using the query makes sense.

LeeHowes commented 6 years ago

Landed #123 to be consistent by using queries. I'm not in favour of going the other way because of the comment above.