Braddock Gaskill:
pair<promise,future> pc = create_channel();
The thought crossed my mind, but there are too many places in real-world usage (I've had a lot now) where I find I want to get a future from a promise. I think it might be awkward to store both, and defeats the intention of automatic cancelation.
Can you please go into more detail? It seems to me that if you need to create futures on demand, then the non-automatic cancelation should not be used. If some future holder calls cancel, later futures created by this promise will not work. I can't think of a situation where this would be desirable. Storing a future in addition to the promise does disable the implicit cancelation - by design; presumably if you need the capability to create more futures at some later point, you don't want the task canceled in the meantime. And if you don't mind the task being canceled since you no longer need to create futures, you just reset() your local future copy.