We have two options: * we wait to review AFIO once Monad is reviewed in Boost * You include in AFIO, whatever you consider is need from Monad and only then we review AFIO.
I can remove monad<T> from all the tutorial code. Or I can include documentation of monad<T> in AFIO. Which would you prefer?
You've mentioned monad<T> is just like std::shared_future<T>, and have said the tutorial could be changed to use the latter. Could the whole library be changed to use std::shared_future<T>. I think the answer is no, so could you expand on why? E.g. does it save typing because otherwise your code is littered with p.get_future().wait() calls? Or does it save having to do tight polling loops, and therefore improves latency? Or some other reason? BTW, does Monad extend proposal N4399? ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4399.html ) Would you recommend I be familiar with that, before reading the Boost.Monad docs (https://ned14.github.io/boost.monad/index.html)? I also have a similar implementation question, regarding asio: in one of your emails (sorry, couldn't find it just now - it might have been something I skimmed in the docs, yesterday), on performance, you said that some of the overhead was adapting to something in asio. I wondered in what way your library is tied to asio, and for what functionality in your library it is an essential part. (Are any parts of the ASIO interface exposed in the AFIO public API, or is it purely an implementation detail?) Thanks, Darren