On Wed, Aug 20, 2025, at 12:40 PM, Claudio DeSouza via Boost wrote:
So I'm not sure how to interpret that, and other Asio contributors could better explain what normally happens in these cases.
That is not the question. The first question is whether we understand what’s actually happening under these descriptions. Your question appears to silently accept the premise that we interpret correctly what is happening, anyways. E.g. in the case of that any_completion_handler PR I think it got paired up with a considerable revamp of the associator traits (although I might suffer from hazy memory and merely remember these changes occurring around the same release). A lot of the time Chris sees a change request as a reason to improve implementation details, often with large impact outside the feature at hand. It would not be practical/fair/possible to require a contributor to redo their feature/change to fit the new plumbing. Another example I remember is Klemens’ idea to make error_code& a completion token per se, so c++20 syntax would not be burdened at all. Some 5-10 releases down the road we not only have a general family of token adapters (consign, as_tuple, redirect_error, cancel_after…) but even a default completion token that changed to default to asio::deferred_t. All in all, not only does redirect_error(ec) more or less do exactly what Klemens’ idea sketched, but we got the far superior solution where c++20 co_await syntax has the best of all worlds regardless of how errors are handled. This is not an example that started with concrete code by Klemens (if memory serves) but it sure serves as an example how the concrete ideas inspire re-imagined solutions rather than verbatim contributions. Again, if we’re gonna stage an investigation into perceived plagiary or use of work without credit, that seems both a derailment of the topic (so warrants its own thread) and requires tangible examples. Seth