Proposed resolution:

This wording is relative to N4771.

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

   [Drafting note: As a drive-by fix, a missing std:: qualification in front of forward has been added]

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

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

   -?- Remarks: This function shall not participate in overload resolution unless the expression rdbuf()->connect(std::forward<Args>(args)...) is well-formed.

2. Modify [socket.iostream.members] as indicated:

   [Drafting note: As a drive-by fix, a missing std:: qualification in front of forward has been added]

   template<class... Args>
     void connect(Args&&... args);
   

   -1- Effects: Calls rdbuf()->connect(std::forward<Args>(args)...). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure).

   -?- Remarks: This function shall not participate in overload resolution unless the expression rdbuf()->connect(std::forward<Args>(args)...) is well-formed.

[ 2020-07-17; Priority set to 3 in telecon ]

Addresses: networking.ts

basic_socket_streambuf<P, C, W>::connect(Args&&...) is constrained to only exist when P meets the InternetProtocol requirements, but basic_socket_iostream<P, C, W>::connect(Args&&...) is not constrained. Since it just passes those arguments straight to the streambuf, the outer connect(Args&&...) should be constrained too.

In addition to that, the basic_socket_iostream(Args&&...) constructor should be constrained, so that is_constructible gives the right answer.