Tracking Issue for addr_parse_ascii feature

[marmeladema]

Feature gate: #![feature(addr_parse_ascii)]

This is a tracking issue for parsing network addresses (IP, Socket, etc) from a slice of bytes.

Internally the parser already works on bytes, this feature exposes publicly the ability to parse network address from a slice of bytes and therefor avoid the need to do utf8 validation in case one has only bytes.

Public API

impl IpAddr {
    pub fn parse_ascii(b: &[u8]) -> Result<Self, AddrParseError> {
}
impl Ipv4Addr {
    pub fn parse_ascii(b: &[u8]) -> Result<Self, AddrParseError> {
}
impl Ipv6Addr {
    pub fn parse_ascii(b: &[u8]) -> Result<Self, AddrParseError> {
}
impl SocketAddrV4 {
    pub fn parse_ascii(b: &[u8]) -> Result<Self, AddrParseError> {
}
impl SocketAddrV6 {
    pub fn parse_ascii(b: &[u8]) -> Result<Self, AddrParseError> {
}
impl SocketAddr {
    pub fn parse_ascii(b: &[u8]) -> Result<Self, AddrParseError> {
}

Steps / History

• Implementation: Support parsing IP addresses from a byte string #94890
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[niklasf]

Bikeshedding: Usually .parse() is called on the input. Perhaps something like IpAddr::from_ascii() is more consistent with FromStr::from_str() and u32::from_str_radix() etc.

[shahn]

Anything blocking an FCP for this feature? Very happy about more non-string APIs getting added

[Turbo87]

I think I support what @niklasf has said above. Function names beginning with from_ for such cases seem to be more common in the std lib for these situations. I would however propose naming it from_bytes() since the function operates on u8 and not ASCII, which is limited to values of 0-127. This would also be consistent with the naming of https://doc.rust-lang.org/stable/std/ffi/struct.OsStr.html#method.from_bytes.

[tgross35]

I have also come across need for this a lot, but not just for these types - almost everything we parse in std is strictly ASCII (e.g. numbers). If this is going to be a common thing, I am thinking that maybe we should have a separate trait like FromStr rather than one off methods, which also gives an nicely usable inherent method on &[u8]

pub trait FromBytes: Sized {
    type Err;

    // Required method
    fn from_bytes(s: &str) -> Result<Self, Self::Err>;
}

impl<T> FromStr for T where T: FromBytes { /* ... */ }

impl<[u8]> {
    pub fn parse<F>(&self) -> Result<F, <F as FromStr>::Err>
        where F: FromBytes,
}

@BurntSushi I know you have had some ideas about improving ascii support in the language, any thoughts here?

Edit: opened an ACP at rust-lang/libs-team#287 to discuss this further

[jmillikin]

I think I support what @niklasf has said above. Function names beginning with from_ for such cases seem to be more common in the std lib for these situations. I would however propose naming it from_bytes() since the function operates on u8 and not ASCII

Parsing a network address "from bytes" usually implies that the bytes are used directly as the network address, which is a fixed-size and non-failable conversion (aka impl From).

struct Ipv4Addr {
  // already implemented as: impl From<[u8; 4]> for Ipv4Addr and IpAddr
  fn from_bytes(bytes: [u8; 4]) -> Ipv4Addr;
}

struct Ipv6Addr {
  // already implemented as: impl From<[u8; 16]> for Ipv6Addr and IpAddr
  fn from_bytes(bytes: [u8; 16]) -> Ipv6Addr;
}

[clarfonthey]

Might I suggest from_byte_str since b"..." literals are called byte strings? If we have [ascii::Char] stable ever then we can call that from_ascii_str, although that would also likely delegate to from_byte_str.

[abonander]

This could be TryFrom<&ByteStr> should std::bstr::ByteStr be stabilized.

[clarfonthey]

Sure, although I also think that having a from_byte_str method isn't particularly harmful either. I like named methods, and const traits aren't stable yet.