Thanks for the feedback! I will respond to your code review comments inline/push changes as needed.
As for the compatibility question
In the ideal case we could provide the non zero abstraction implementation for async_result for older boost asio versions and switch to the improved one when a suficient version number is detected (which can be done through ASIO_VERSION or BOOST_VERSION macros which should be exposed somehow by the implementation). Same gos for the MSVC bug you mentioned, is this possible?
That's a good idea so some points are probably worth clarifying.
Re: non-zero overhead version:
This is doable and probably worth pursuing. However there are three possible tiers of integration.
1. Best case: ASIO >= 1.15, Boost >= 1.72, zero-overhead adaptation. We have the lazy form
async_result::initiate plus return type deduction
Not bad: ASIO >= 1.14, Boost >= 1.70, adaptation with type erasure on the continuable. We still have the
async_result::initiatewhich allows lazy initiation of async ops, but
return_typemust be specified purely based on signature. So we can do
return_type = cti::continuable<_result_type_>which, if I understand right, uses your
function2type erasure. Still not bad!
Worst case: prior versions. Have to specify
return_type, and only the
async_result::getform exists, which requires eager initiation.
If I'm reading the invocation model docs correctly, case 3 is incompatible with the continuable invocation model, as it requires eager initiation. For example I am not doing this in my example code currently, but I could write
auto ct = asio::async_meow(use_cti_t); And then nothing is actually initiated until I call
ct is destructed, etc (possibly with some
fail chained on beforehand). But strictly speaking this is illegal with the
So if I'm understanding right, we want to provide support for both 1. and 2., but for 3. the recommendation remains to use
promisify and/or follow the example of the existing
example-asio.cpp? In this case we could even add macro checking to
support/asio.hpp and say older versions are not supported.
Regarding the MSVC bug, this is indeed possible and trivial to do but I would argue not necessary. ASIO and Boost.ASIO both follow a release schedule with discrete releases, so I think we will say something like "here is ASIO support for ASIO >= 1.14 or Boost >= 1.70". But right now I am coding against some stray commits from the Boost 1.72/ASIO 1.15 beta, but I do expect the MSVC fix to make it into the actual 1.72/1.15. Again this is low effort to support, but arguably not really necessary as I imagine users tend to lock into release versions rather than random commits.
Those are my thoughts, but happy to go with whatever you see fit!