asio-tr2
asio-tr2 copied to clipboard
chriskohlhoff
Reconsider ip::address default constructor
The proposal currently specifies that a default constructed ip::address have is_ipv4() == false and is_ipv6() == false. Or to put it another way, the ip::address class can contain:
- an IPv4 address; or
- an IPv6 address; or
- a Not-An-Address value
So right now the ip::address class can represent a value that is outside the domain of valid IP addresses. This is not the established practice in Asio and as I implement this I am finding that it might cause inconsistencies in the other types that use ip::address, like ip::basic_endpoint.
So far I've got three options:
- Option 1: Revert to asio behaviour, i.e. ip::address() == ip::address_v4()
- Option 2: Keep current behaviour, fudge the endpoint and protocol classes (i.e. current wording might be ok)
- Option 3: Keep current behaviour, change InternetProtocol requirements to add Protocol::unspecified()
It seems that Option 1 has the advantage of being known to work well. The other options seem to open the door to possible side-effects yet to be well understood.
- Option 4: Make it an error (exception?) to construct an endpoint from a default-constructed
ip::address
Thinking about Option 4 I could see how allowing a 'not an address' state could lead to lots of validity checking in user code that takes an ip::address either pre-emptively or in response to a possible exception. Of course users should probably pass values and let them be dealt with by objects that care (like endpoint) but I can envisage many not doing that.
Decision in Cologne meeting was to return to the existing experience of Asio. I.e. remove the 'not an address' state and default-construct as an IPv4 address.
Pre-Lenexa Summary
The original asio design of ip::address was that an address is either IPv4 or IPv6. A default constructed address is the IPv4 any address.
During SG4 discussion of the separate IP Address proposal, the design was changed to introduce a not-an-address value as the default. As described above, adding this out-of-domain value caused some consistency problems when incorporated into the wider Asio-based proposal, e.g. in the basic_endpoint default constructor. It also significantly complicated the specification of some functions, like the ip::address relational operators.
When we discussed about this in Cologne, we decided that we should return to Asio's original behaviour. LEWG needs to confirm this decision.
The change was included in revision 5. An implementation can be found on the master branch of Asio's GitHub repository.
