Boost logo

Boost :

Subject: Re: [boost] [afio] AFIO review postponed till Monday
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-22 21:40:16

On 22 Jul 2015 at 15:16, Michael Caisse wrote:

> On 07/22/2015 09:01 AM, Niall Douglas wrote:
> > Futures gives you the option of monadic programming, and they enforce
> > strict operation ordering very succintly. They are the right choice
> > for file i/o, just as async_result is the right choice for network
> > i/o.
> Is there somewhere in the documentation/rational that you explain this
> (right choice) comparison further?

There once was, but I deleted it as it generated emails to me telling
me why I was wrong :)

I don't mind restoring such a section now that I have lightweight
futures which do I think address most of the problems that the
async_result camp have with futures. Do you think I should
incorporate this rationale into the design rationale, the tutorial,
or the FAQ?

After all, the choice of futures is strictly speaking not the
controversial choice. They are the STL choice, and if anything it
should be controversial to not be choosing the STL choice rather than
the other way round.

I also feel a bit wary of getting too deeply into futures because I
know the monadic programming camp (let's call them the Bartoz camp)
aren't going to be happy with my interpretation of "monad".

But if you and the community feel I need to justify the choice of
futures as the async operation reference mechanism, I can do that. In
any case I will need to discuss the reason I deliberately allow
implicit type slicing between afio::future<T> and afio::future<void>,
I already can see gnashing of teeth is going to happen from that
design decision, and that could be part of a wider discussion.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at