Change:
impl FromStr for SocketAddrV6 { type Err = AddrParseError; fn from_str(s: &str) -> Result<SocketAddrV6, AddrParseError> { <del> Parser::new(s).parse_with(|p| p.read_socket_addr_v6(), AddrKind::SocketV6) </del> <ins> Self::parse_ascii(s.as_bytes()) } } impl SocketAddr { /// Parse a socket address from a slice of bytes. /// /// ``` /// #![feature(addr_parse_ascii)] /// /// use std::net::{IpAddr, Ipv4Addr, Ipv6Addr, SocketAddr}; /// /// let socket_v4 = SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 8080); /// let socket_v6 = SocketAddr::new(IpAddr::V6(Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 1)), 8080); /// /// assert_eq!(SocketAddr::parse_ascii(b"127.0.0.1:8080"), Ok(socket_v4)); /// assert_eq!(SocketAddr::parse_ascii(b"[::1]:8080"), Ok(socket_v6)); /// ``` #[unstable(feature = "addr_parse_ascii", issue = "101035")] pub fn parse_ascii(b: &[u8]) -> Result<Self, AddrParseError> { Parser::new(b).parse_with(|p| p.read_socket_addr(), AddrKind::Socket) </ins> } }

Discussion:
The only standard way I've found to parse an IP address is . That function immediately converts the string to bytes: It would be great to expose some way (not necessarily , but something similar) that doesn't require doing unnecessary utf8 validation. label: +T-libs +C-enhancement <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi where is the utf8 validation happening? As you said, the string slice gets converted to a byte slice but then it looks like the parser just works with s which get cast to s at some points in the algorithm
it happens before you ever pass the string to : I have a byte sequence, and in order to parse it, I'm forced to call .
implements for arrays [u8; 4] and [u8; 16]
I don't have an array. I have a dynamically sized &[u8], and I'm not sure whether it's a valid IP address or not.
Gotcha. If this is a valid ipv6 address (so it has at least 16 bytes) but the first four bytes make up a valid ipv4 address too then we'd have to make a decision. We could require that the be of size 4 or 16 then we'd know how to interpret it?
claim
4 and 16 are misleading I think. This is a normal IP address, like "127.0.0.1", it just happens to have come from the network and not be utf8 validated. "127.0.0.1" is 9 bytes, and in general, IP addresses can be variable length.
If the address, say "127.0.0.1", comes from the network, as inside an IPv4 header, then it must be a 32 bit value, it would be of the form but utf8 encoded IP addresses would have variable length as you said so maybe that is what you're referring to receiving on the network?
We could add something like this and add in the docs that this parses IP addresses and assumes that they're utf8 encoded?
It doesn't.

No part of that code requires to be utf8 encoded - if it contains a non-utf8 byte, then it's not a valid IP address anyway, and it returns like normal.
I disagree. The slice of bytes must represent an IP address string in dot notation so the slice of bytes "encodes" this string; some comment should be to the docs to explain what the slice of bytes is. For instance, this slice of bytes is bad and would cause a parse error. It doesn't contain non-utf8 byte but it doesn't encode an IP address string in dot notation. instead it should be This is what does - we get the underlying bytes encoding the string.
Oh, I see what you mean - you're saying that it should be a byte string, and not an array of the ip numbers. Yes, I agree that's what the code is doing.
So is this issue for exposing a new way to parse ip byte strings or a slice of the ip numbers? Not sure how to move forward. Thanks for working with me on this btw.
I don't understand the question. I have and I want to turn it into an IpAddr.
This made me think that you were taking about an array/slice of the numbers of the ip address and not a byte string. Actually, I'm gonna let someone else have a crack at this. There's some useful info here and enough to get started. release-assignment