Hi Everyone, I've been following the future implementation proposals that are set to be available for review soon for inclusion in Boost. I for one would like to look at the implementations in their "review-ready" forms before doing an actual review of the different (competing?) implementations. However, before it goes out there, I would like to throw something into the mix. Right now, we've been discussing futures that contain individual values -- I know, these values can be containers, or practically anything that can be referred to with a pointer. That being said, I'd like to look at a broader application of future containers in the form of asynchronous random access containers. First, let me set up why I'm interested particularly in this matter. I'm looking at being able to map a function to a range and being able to asynchronously access certain parts of the container from multiple threads and perform operations on them. This marries the functional programming notion of function application, with asynchronous/parallel programming with "lazy values" -- only here, the values are actually computed in parallel or in separate threads (accessed through futures). So given for example: transform( input.begin(), input.end(), back_inserter(output), function_returns_future ); It would make 'output' be a back insertion sequence (or a container that supports .push_back) that contains futures. Now this would be fine, but now the problem becomes this: In the case of an associative container for example, we'd have a pair<key, future<value> > -- since futures cannot be default constructable in either implementation, I don't think code that does something like: map<int, future<int> > container; container[0].wait(); // dunno what happens here Will compile. Right now, having futures non-default constructable makes it hard(er) to put them in standard containers. 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". Is there a thrust towards developing a future-aware class of containers parallel to the STL containers? I personally think this will be a game changer in helping people transition towards and actually maximizing futures. I'd love to hear your thoughts on this. Have a good day everyone. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.