Tracking issue for IP constructors

[jcdyer]

Tracking issue for IP address convenience constructors, added in #44395, modified in #52872.

impl Ipv4Addr {
    pub const LOCALHOST: Self = Ipv4Addr::new(127, 0, 0, 1);
    pub const UNSPECIFIED: Self = Ipv4Addr::new(0, 0, 0, 0);
    pub const BROADCAST: Self = Ipv4Addr::new(255, 255, 255, 255);
}

impl Ipv6Addr {
    pub const LOCALHOST: Self = Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 1);
    pub const UNSPECIFIED: Self = Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 0);
}

Is there any way to implement these as constants?

I personally don't like this kind of trivial function.

[Diggsey]

See also #39819

[SimonSapin]

I’d also like these to be associated const items instead. This would require at least these APIs to be made const fn:

• Ipv4Addr::new
• Ipv6Addr::new
• std::net::hton
• u32::to_be
• u32::swap_bytes

If we’re doing down this road, it seems like many more APIs should also be const fns for consistency, which is starting to be out of scope for this issue.

@rust-lang/libs what do you think?

[sfackler]

I think I'd prefer these to be associated consts as well. We don't necessarily need to make all of those functions const as well - we can just directly initialize the structures.

[SimonSapin]

Hmm yes, I suppose we could replace the hton call with two definitions based on target endianness #[cfg].

[Kixunil]

Maybe I'm missing something, but aren't IP addresses independent of endianness? In other words, aren't they [u8; 4]?

[sfackler]

An Ipv4Addr is a wrapper around the libc in_addr type, which has a u32 field that needs to hold the IP in big endian.

[SimonSapin]

Right. [u8; 4] would be a fine way to store it in big-endian with cross-platform code, but Because Reasons the internal type is ultimately big-endian u32.

[Kixunil]

OK, thanks for explaining! An alternative would be to just transmute(), but I'm not sure if transmute() is a const fn.

[SimonSapin]

I think I’d prefer this over transmute:

        Ipv4Addr {
            inner: c::in_addr {
                // 127.0.0.1
                #[cfg(target_endian = "big")]
                s_addr: 0x7F_00_00_01_u32,
                #[cfg(target_endian = "little")]
                s_addr: 0x01_00_00_7F_u32,
            }
        }

(Either way, with an assert_eq!(Ipv4Addr::LOCALHOST, Ipv4Addr::new(127, 0, 0, 1)) test.)

[SimonSapin]

The libs team discussed this and the consensus was to stabilize this as associated constants (in uppercase: LOCALHOST and UNSPECIFIED.)

@rfcbot fcp merge

[rfcbot]

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.