Bumping language requirement to C++14

[ecorm]

UPDATE: I no longer need to bump the language requirements and can keep them at C++11.

---

I'm trying to get C++20 coroutines to work in my completion-tokens development branch, and have run into the problem that it's impossible to store a Boost awaitable_handler in a std::function due to the former being move-only.

I want the type erasure provided by std::function, as this allows CppWAMP to be compiled as a static library. Our parent project that uses CppWAMP is already slow to compile, so I'm not in favor of making CppWAMP purely header-only.

I therefore need an implementation similar to C++23's std::move_only_function. The best I could find was fu2::unique_function from https://github.com/Naios/function2, but it requires C++14. I don't have time to write my own production-quality move_only_function, so I'd prefer to use fu2::unique_function.

I could wrap the awaitable_handler in a std::shared_ptr as was done by a CppWAMP user who made their own adapter to use C++20 coroutines with CppWAMP. However, I am concerned with the efficiency of this approach, which does not have the small buffer optimization featured by std::function and the like.

Naios/function2 is a single header that's also Boost-licensed, so I would simply bundle it with CppWAMP and provide credit in the README. I'll provide a preprocessor mechanism that allows users to supply their own function2.hpp header.

I'm therefore strongly considering bumping the the language requirements for CppWAMP to C++14. Doing so would provide these additional maintenance benefits:

• Move capture in lambdas (no need for CPPWAMP_MVCAP macro)
• Generic lambdas eliminate need for DoConnect, DoJoin, etc functors in Session
• Automatic return type deduction instead of -> decltype(initiate<DoConnect>(std::forward<C>(completion))) mess
• std::integer_sequence instead of DIY variety

Please note that supporting C++20 coroutines does not imply that the minimum language requirements for CppWAMP will also be C++20. Only C++20 coroutine users will have the requirement of a C++20 compiler.

[ecorm]

*crickets*

Heh, I guess former CppWAMP users must have moved on to other libraries/technologies. 😄

[ecorm]

The problem goes deeper than std::function not being able to wrap a move-only awaitable_handler. I need to dispatch user handlers using the associated executor obtained via boost::asio::get_associated_executor. If I fail to do that, it will ignore instances where the user wraps their handler with boost::asio::bind_executor. There's also boost::asio::get_associated_allocator that I also might have to deal with.

I've stumbled upon this issue report where the author of Boost.Beast says that std::function can't be used as a generic type-erased handler wrapper: inetic/asio-utp#3

I've made a feature request for a type-erased asynchronous handler wrapper on the Asio GitHub issue tracker: chriskohlhoff/asio#1100

I cross-posted the same feature request to the C++ proposals mailing list: https://lists.isocpp.org/std-proposals/2022/07/4223.php

[ecorm]

I ended up having to write my own async handler wrapper and did not need C++14. I'll be keeping CppWAMP's language requirements at C++11 unless something comes up that forces me to increase it.