On 28/08/2015 15:16, Niall Douglas wrote:
afio::future<> has a single errored or exceptioned state.
Then FYI, the wording of the first Description paragraph in https://boostgsoc13.github.io/boost.afio/doc/html/afio/reference/classes/fut... is potentially confusing in that regard, since it seems to be discussing error states for "both".
I suppose you're right, it's not far from being a std::future<std::tuple<afio::handle_ptr, T>>. The big problem with std::future<std::tuple<afio::handle_ptr, T>> is it's ABI poison because of the unknown T passing through an ABI boundary, so you'd have to type erase which means an extra memory allocation before crossing the ABI.
Perhaps I'm missing something again, but where do you need to do that? If you mean when passing preconditions back, that could still just discard T to void as you're doing now -- assuming you can convert a tuple<handle_ptr, T> to tuple<handle_ptr, void> or tuple<handle_ptr>. Again, I'm not sure how complex this is or whether it would be "worth it", but it does seem like a cleaner design to treat the handle and other data as the composite value of the future. Another possibility would be to explicitly separate the handle_ptr. Most functions would then change from accepting a future<void> to accepting a future<handle_ptr>, since that's the value they actually need to do the work. For dependency order tracking you can just use the depends() helper you mentioned earlier, eg: afio::future<handle_ptr> openfile = afio::async_file(...); afio::future<void> resizedfile = afio::async_truncate(openfile, 12); ... afio::future<void> written = afio::async_write(depends(resizedfile, openfile), buffers, 0); ... So the write depends on resizedfile being done, but that *doesn't* carry a file handle -- the only one that does is openfile. (depends, of course, would tolerate different Ts for its parameter futures, and will return the second one's type.) This is perhaps more like how people are used to working with futures, rather than having them carry around extra values. The only possibly tricky part that I foresee is that anything calling then() will need to know the T of the specific future, but hopefully that's trivial in most cases. (And other than depends()' first parameter, you can probably get away with assuming that it's either void or handle_ptr most of the time.)