From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-12 10:38:42
Christopher Kohlhoff wrote:
> Unlike the various futures proposals that are around, I prefer to keep the
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk