On Mon, May 19, 2008 at 9:36 PM, Frank Mori Hess <frank.hess@nist.gov> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday 18 May 2008 22:40 pm, Dean Michael Berris wrote:
Right now, having futures non-default constructable makes it hard(er) to put them in standard containers.
I believe futures should be default constructible. The William's future already have an "empty" state, which can be reached by moving a future. I made poet::future default constructible so they could be used in containers, and made default constructed futures throw an exception if someone attempts to wait on them.
This sounds like a good idea, waiting on a future that doesn't have an associated promise should throw.
This now begs the question: Will there be, or should there be, special classes of future containers that would specially be defined to work with futures? For example, in associative containers we should be able to access the elements using the index operator without having to explicitly call 'wait()', or perhaps have special future container iterators that allow for waiting on a future when dereferencing "pointed to elements".
Would this add anything besides automatically waiting for futures to become ready when they are accessed? Automatic waiting is the reason some people don't like implicit conversion of futures to values (I actually don't like it so much myself any more). They want points in the program where a future might block to be as explicit as possible.
For the special container types I've been pondering, aside from automatically waiting on contained futures there's the possibility of making standard algorithms more specialized for these container types (or via tag dispatch). Perhaps having a special std::transform() implementation (the five argument version) that does a 'wait on any' future in the container and in a non-deterministic order apply a function on the contained future value that becomes available, and the result mapped to the appropriate location in the resulting container. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.