Re: [boost] [next gen future-promise] What to callthemonadicreturntype?

Giovanni Piero Deretta wrote:

On 26 May 2015 12:59 am, "Peter Dimov" wrote:

...

This non-allocating implementation is an interesting argument in favor of the current "unique future", which I've long disliked. I prefer futures to be shared_futures.

Interesting, why do you dislike the unique future design?

I dislike the unique/shared future split, which requires all algorithms to be duplicated/manyplicated. auto f = when_any( f1, f2, f3, f4 ); // 2^4 options I prefer a single future<T> type, and I want this single type to be shared because I want the above when_any to not std::move my futures, leaving me with empty shells.

A shared future pretty much requires holding a shared pointer and needs heavy weight synchronisation ( a muted+condvar or equivalent). On the other hand a unique future need no internal mutual exclusion and the only synchronisation is needed for the handoff between producer and consumer; the reference count is implicit (just have the consumer always deallocate the object). The implementation can be significantly more light weight.

I already acknowledged that these implementations are an argument in favor of unique future. But I don't think I agree with what you're saying. I don't see how mutex+condvar is required by shared future but not by unique future (how do you implement wait() is not related to sharedness), neither do I see how unique futures require no synchronization (they obviously do in Niall's implementation.)