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, 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..?
