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/fut... 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
, 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
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.