Christopher Kohlhoff wrote:
Unlike the various futures proposals that are around, I prefer to keep the producer and consumer interfaces separate. Hence I have promise<T> (producer interface) and future<T> (consumer interface) -- these names are borrowed from the Alice programming language.
promise<> is an interesting name. The best with which I was able to come up so far was source<>. I also like the (obvious in hindsight) approach of making future<> constructible from promise<>. I was exploring something like pair< future<R>, source<R> > create_channel(); This does have the advantage that producers can only get a source/promise and consumers can only get a future, but I wasn't quite satisfied with it. To elaborate on Chris's point, the significance of keeping the producer and the consumer interface separate is that it allows future<R> to be made convertible to future<R2> whenever R is convertible to R2 (or R2 is void); this also allows extensions in the spirit of Frank Mori Hess's operator[], while still preserving the full generality of the producer (i.e. doesn't tie it to a specific executor). I didn't have time before the deadline to flesh out such a design, but if someone is willing and able to defend a similar proposal in Oxford, I will be glad to help with it.