On Tue, Aug 23, 2022 at 4:23 PM Gavin Lambert via Boost
url_base& url_base::set_port( string_view ); // throws result<void> url_base::try_set_port( string_view ); // returns result
Why is it a string at all? Shouldn't it be exclusively a uint16_t?
Its a good question. Every member function in the reference has a BNF section which shows the grammar, and a Specification section which provides a link to the relevant specifications document (RFC3986 in this case): https://master.url.cpp.al/url/ref/boost__urls__url_base/set_port/overload2.h... The RFC says: port = *DIGIT That means that "80", "443", and "8080" are examples of valid ports. "65535" is a valid port. But so is "4294967295" or even "999999999999999999". In fact "0" is a valid port, as well as "00" or any number of leading zeroes, followed by any number of digits (including no digits). And the empty string "" is a valid port. Boost.URL recognizes the distinction between having a port which is the empty string, and not having a port at all, by providing the function remove_port() and the function has_port(). Calling set_port("") is semantically different from calling remove_port(), and results in a different URL. This is per the RFC grammar: authority = [ userinfo "@" ] host [ ":" port ] Because this library is capable of representing ALL URLs, it is necessary for the interface to allow the caller to interact with the port as a string which is valid according to the grammar. But of course people need to treat it like an integer so we have overloads for setting the port as a sixteen bit unsigned number, and retrieving the port as the same. https://master.url.cpp.al/url/ref/boost__urls__url/port_number.html https://master.url.cpp.al/url/ref/boost__urls__url/set_port/overload1.html Regards