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-30 20:10:31

On 29/08/2015 10:36, Niall Douglas wrote:
> On 28 Aug 2015 at 17:18, Gavin Lambert 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/future.html
>> is potentially confusing in that regard, since it seems to be discussing
>> error states for "both".
>
> It means both get() and get_handle().

I realise that, but it also seems to imply that each have separate error 
state.  The clause about error state being "identical for both" is 
perhaps an attempt to defuse that interpretation, but I'm not sure it 
works.  Though again maybe I'm just being too nitpicky.

>> 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.
>
> I'd live comfortably with what you just proposed. In fact, it was my
> second preference API design after the one I chose. I felt originally
> that making the end user write depends() all over the place would be
> irritating, but maybe it's better to force the end user to always be
> explicit about what operations relate to which others.

I think this might end up being a little cleaner, despite being more 
verbose at first glance.  In theory then all the functions that accept 
preconditions would just be very thin wrappers that simply "return 
precondition.then(actual operation)" (or similar; I'm not sure if you 
need an extra layer to cope with "depends" returning an unready future).

If the "actual operation" API were also public then this might also 
satisfy the folks in the other thread that want to avoid having 
precondition parameters at all.

Bear in mind that once coroutines or async/await are better established 
in the language, it's likely that there would be no need for 
precondition parameters as it would be simpler to attach continuations 
at the top level.