Introduce unstable Ipv{4,6}AddrPrefix

[CDirkx]

This PR introduces types representing IP address prefixes such as 192.0.2.0/24, as suggested in #86969 (comment).

Feature gate: #![feature(ip_prefix)]
Tracking issue: #86991

Overview

Ipv4AddrPrefix

#[derive(Copy, PartialEq, Eq, Clone, Hash)]
pub struct Ipv4AddrPrefix {
    address_raw: u32,
    len: u8,
}

impl Ipv4AddrPrefix {
    pub const fn new(address: Ipv4AddrPrefix, len: u32) -> Result<Ipv4AddrPrefix, InvalidPrefixError>;
    pub const fn address(&self) -> Ipv4Addr;
    pub const fn len(&self) -> u32;
    pub const fn contains(&self, address: &Ipv4Addr) -> bool;
}

impl Debug for Ipv4AddrPrefix  {}
impl Display for Ipv4AddrPrefix  {}
impl From<Ipv4Addr> for Ipv4AddrPrefix  {}
impl FromStr for Ipv4AddrPrefix  {}

Ipv6AddrPrefix

#[derive(Copy, PartialEq, Eq, Clone, Hash)]
pub struct Ipv6AddrPrefix {
    address_raw: u128,
    len: u8,
}

impl Ipv6AddrPrefix {
    pub const fn new(address: Ipv6AddrPrefix, len: u32) -> Result<Ipv6AddrPrefix, InvalidPrefixError>;
    pub const fn address(&self) -> Ipv6Addr;
    pub const fn len(&self) -> u32;
    pub const fn contains(&self, address: &Ipv6Addr) -> bool;
}

impl Debug for Ipv6AddrPrefix  {}
impl Display for Ipv6AddrPrefix  {}
impl From<Ipv6Addr> for Ipv6AddrPrefix  {}
impl FromStr for Ipv6AddrPrefix  {}

This PR doesn't make any changes yet to the Ipv{4,6}Addr types themselves.

Unresolved Questions

Is the naming clear? Is this the correct abstraction?

[CDirkx]

Python uses the name IPv6Network, but I chose the less generic name Ipv4AddrPrefix.

[CDirkx]

len stored as an u8 to reduce size, however new and len use/return a u32 (chosen that way to have the same type as {u32, u128}::BITS).

[the8472]

Well, it reduces size but not alignment. So if you put into an array there wouldn't be any savings.

[CDirkx]

Constructor is fallible, unlike the IpvAddr and SocketAddr constructors, because the prefix length can not be longer than there are bits.

[CDirkx]

Not sure which methods should or shouldn't be inlined.

[the8472]

As mentioned in the other PR, having a mask instead of a prefix would be more powerful. The prefix could still be passed as a convenience constructor.
One example case where this is useful is dynamic ipv6 prefix delegation where each machine still has a fixed suffix. So you can identify a machine by matching a suffix instead of a prefix.

[CDirkx]

Changed from Ipv4Addr to a u32 to avoid storing potential extra fields of c::in_addr. Same thing for Ipv6AddrPrefix. This could be reverted if #78802 ever gets merged.

[CDirkx]

I agree that the ability to do computations with address masks should be added, like you said comparing addresses and using a subnet mask (255.255.255.0) or wildcard mask (0.0.0.255) would be very useful. However I don't think that functionality should be included in these IpAddrPrefix types, but instead as methods on the IpAddr types (or a separate IpAddrMask type, see CDirkx@2e17cd8 for what I think that could look like).

An address + prefix (1.2.3.0/24) to describe a range is a fundamental concept enough to warrant its own type in my opinion, in a way address + arbitrary mask isn't. Python's IPNetwork classes also only represent address + prefix, but I can look into what other languages are doing regarding prefixes, masks etc.

[the8472]

An address + prefix (1.2.3.0/24) to describe a range is a fundamental concept enough to warrant its own type in my opinion, in a way address + arbitrary mask isn't.

But a mask can everything a prefix can, so why not implement the more powerful concept?

[bors]

☔ The latest upstream changes (presumably #85769) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnCSimon]

Ping from triage:
@CDirkx can you please address the merge conflict?

[JohnCSimon]

Triage:
@the8472 - seems that this PR has been inactive for over two months. I'm closing this as inactive. Please feel free to reopen if you want to continue on this. Thank you.

[the8472]

@JohnCSimon I'm not the PR author.