On 28/08/2015 13:47, Niall Douglas wrote:
Thomas has also argued that each async_* function should return only a future specific to its return type, so instead of afio::future<T> always transporting a future handle in addition to any future T, you must supply (I would suppose) two futures to every async_* function, one for the handle, the other as the precondition. I asked if he could propose an API based on that model which is substantially superior to the one used by AFIO, because if he can I'll take it.
I think rather than transporting separate futures he was suggesting something more like using afio::future<afio::handle_tuple<T>>, where "future" is a traditional Concurrency future that transports T or errors and no other state, and "handle_tuple" is a tuple type that transports a handle (and any other internal state that APIs might want, eg. I think you mentioned at one point that it also transports the filename of that handle, for the rmfile case?), plus the desired T for the operation in question. ie. separation of types rather than conflation. Personally, I'm not sure if the extra typing is worth it (and I haven't looked into any other tradeoffs this might bring), but I can see his point (assuming that I am correctly interpreting it). This does of course assume that the handle and the T become ready at the same time and that they don't have separate error states, but given the comments in the docs that preconditions are treated as future<void> anyway and your own comments about default construction on error, I don't think this is a hardship. Please correct me if I've missed something. Perhaps a reasonable compromise might be that a handle-transporting future should be called "handle_future" or "future_handle" or "hfuture" or similar instead of plain "future", to avoid overloading the buzzword. But this might just be bikeshedding again. Although on a related note, having a single future class with a handle-part that's non-consuming and a T-part that's consuming seems potentially confusing. I assume there is some performance argument behind this design choice..?