Upgrading from C++17 to C++20, encountering a build error in Boost, async_accept() when using boost::asio::use_future as second argument

Question

OS: Ubuntu 22.04 Compiler: gcc 11.3 Boost Version: 1.80

Working on upgrading an existing project from C++ standard C++17 to C++20. Everything compiles in C++17 but when upgrading to C++20, an error is being generated in acceptor_.async_accept when the second argument is boost::asio::use_future.

The problem can be replicated using a different project from Boost sample source code with some slight modifications.

https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/example/cpp03/ssl/server.cpp

changing

  void start_accept()
  {
    session* new_session = new session(io_context_, context_);
    acceptor_.async_accept(new_session->socket(),
        boost::bind(&server::handle_accept, this, new_session,
          boost::asio::placeholders::error));
  }

to

  void start_accept()
  {
    session* new_session = new session(io_context_, context_);
    auto accept_result = acceptor_.async_accept(new_session->socket(), boost::asio::use_future);
    // ....
  }

The error being generated is

/usr/include/c++/11/type_traits:809:68: error: ‘boost::asio::basic_socket<Protocol, Executor>::~basic_socket() [with Protocol = boost::asio::ip::tcp; Executor = boost::asio::any_io_executor]’ is protected within this context
  809 |     template<typename _Tp, typename = decltype(declval<_Tp&>().~_Tp())>
      |                                                ~~~~~~~~~~~~~~~~~~~~^~
/include/boost/asio/basic_socket.hpp:1845:3: note: declared protected here
 1845 |   ~basic_socket()

Changing the second argument in acceptor_.async_accept from boost::asio::use_future to a different argument allows the program to compile but doing this change loses the current functionality.

Answer 1

It's a problem with the GNU standard library implementing the is_destructible trait too strictly for the completion_token_for<> concept.

clang++-15 doesn't seem to mind. Which of the two is right, I am not sure.

For now, a workaround would be to disable Asio's concept support (defining BOOST_ASIO_DISABLE_CONCEPTS). Just disabling the use of standard-library concepts (BOOST_ASIO_DISABLE_STD_CONCEPTS) does not seem to remove the specific problem.

FWIW the problem persists with g++-12 and Boost 1.82.0.beta1.

It doesn't appear to be a problem with g++-10 yet, which I think is the latest version that Asio CI/CD pipeline tests with (see https://github.com/chriskohlhoff/asio/actions/runs/4384634758)