Proposed resolution:

This wording is relative to N4771.

1. Modify [socket.iostream.cons] as indicated:

   basic_socket_iostream();
   

   -1- Effects: Initializes the base class as basic_iostream<char>(&addressof(sb_)), value-initializes sb_, and performs setf(std::ios_base::unitbuf).

   explicit basic_socket_iostream(basic_stream_socket<protocol_type> s);
   

   -2- Effects: Initializes the base class as basic_iostream<char>(&addressof(sb_)), initializes sb_ with std::move(s), and performs setf(std::ios_base::unitbuf).

   basic_socket_iostream(basic_socket_iostream&& rhs);
   

   -3- Effects: Move constructs from the rvalue rhs. This is accomplished by move constructing the base class, and the contained basic_socket_streambuf. Next basic_iostream<char>::set_rdbuf(&addressof(sb_)) is called to install the contained basic_socket_streambuf.

   template<class... Args>
     explicit basic_socket_iostream(Args&&... args);
   

   -4- Effects: Initializes the base class as basic_iostream<char>(&addressof(sb_)), value-initializes sb_, and performs setf(std::ios_base::unitbuf). Then calls rdbuf()->connect(forward<Args>(args)...). If that function returns a null pointer, calls setstate(failbit).

[ 2020-11-09 Approved In November virtual meeting. Status changed: Ready → WP. ]

[ 2020-07-17; Moved to Ready in telecon ]

Jens suggested we should have blanket wording saying that when the library uses the & operator, it means std::addressof.

Addresses: networking.ts

[socket.iostream.cons] uses &sb_ which could find something bad via ADL.