Re: [boost] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-08-27 22:48:18

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