Constify `std::net::IpAddr`, `Ipv4Addr`, and `Ipv6Addr` #76205

CDirkx · 2020-09-01T16:52:35Z

Due to recent stabilizations of const integer arithmetic and const control flow, all methods of types std::net::IpAddr, Ipv4Addr, and Ipv6Addr can be made const. This issue provides an overview of all methods and steps that need to be taken:

`Ipv4Addr`

Methods already stable const:

new
is_unspecified

Methods unstable const by PR#76142 (const_ipv4):

octets
is_loopback
is_private
is_link_local
is_shared (unstable)
is_ietf_protocol_assignment (unstable)
is_benchmarking (unstable)
is_multicast
is_documentation
is_global (unstable)
is_reserved (unstable)
is_broadcast
to_ipv6_compatible (deprecated?)
to_ipv6_mapped

None of these methods depends on an unstable feature, and could all thus be made stable const.

`Ipv6Addr`

Methods already stable const:

new (uses #[allow_internal_unstable(const_fn_transmute)])
octets

Ipv6Addr::segments has been made unstable const in PR#76206 (const_ipv6), together with all dependent methods:

segments
is_unspecified
is_loopback
is_global (unstable)
is_unique_local (unstable)
is_unicast_link_local_strict (unstable)
is_documentation (unstable)
multicast_scope (unstable)
is_multicast
to_ipv4_mapped (unstable)
to_ipv4

All of these methods depend on segments, and thus upon the unstable feature const_fn_transmute, however the transmute is only used for better code generation, the operations could be rewritten equivalently using stable const code.

`IpAddr`

The following methods are stable const:

is_ip4
is_ipv6

Implemented in PR#76226.

With the relevant methods of Ipv4Addr and Ipv6Addr made const, the following were also made unstable const in PR#76304:

is_documentation (unstable)
is_global (unstable)
is_loopback
is_multicast
is_unspecified

The text was updated successfully, but these errors were encountered:

Make the following methods of `std::net::Ipv6Addr` unstable const under the `const_ipv6` feature: - `segments` - `is_unspecified` - `is_loopback` - `is_global` (unstable) - `is_unique_local` - `is_unicast_link_local_strict` - `is_documentation` - `multicast_scope` - `is_multicast` - `to_ipv4_mapped` - `to_ipv4` Changed the implementation of `is_unspecified` and `is_loopback` to use a `match` instead of `==`. Part of rust-lang#76205

Make all methods of `std::net::Ipv6Addr` const Make the following methods of `std::net::Ipv6Addr` unstable const under the `const_ipv6` feature: - `segments` - `is_unspecified` - `is_loopback` - `is_global` (unstable) - `is_unique_local` - `is_unicast_link_local_strict` - `is_documentation` - `multicast_scope` - `is_multicast` - `to_ipv4_mapped` - `to_ipv4` This would make all methods of `Ipv6Addr` const. Changed the implementation of `is_unspecified` and `is_loopback` to use a `match` instead of `==`, all other methods did not require a change. All these methods are dependent on `segments`, the current implementation of which requires unstable `const_fn_transmute` ([PR#75085](rust-lang#75085)). Part of rust-lang#76205

Make all methods of `std::net::Ipv4Addr` const Make the following methods of `std::net::Ipv4Addr` unstable const under the `const_ipv4` feature: - `octets` - `is_loopback` - `is_private` - `is_link_local` - `is_global` (unstable) - `is_shared` (unstable) - `is_ietf_protocol_assignment` (unstable) - `is_benchmarking` (unstable) - `is_reserved` (unstable) - `is_multicast` - `is_broadcast` - `is_documentation` - `to_ipv6_compatible` - `to_ipv6_mapped` This would make all methods of `Ipv6Addr` const. Of these methods, `is_global`, `is_broadcast`, `to_ipv6_compatible`, and `to_ipv6_mapped` require a change in implementation. Part of rust-lang#76205

Make the following methods of `std::net::IpAddr` unstable const under the `const_ip` feature: - `is_unspecified` - `is_loopback` - `is_global` - `is_multicast` Also adds a test for these methods in a const context. Possible because these methods delegate to the inner `Ipv4Addr` or `Ipv6Addr`, which were made const, and the recent stabilization of const control flow. Part of rust-lang#76205

@ecstatic-morse

Make delegation methods of `std::net::IpAddr` unstably const Make the following methods of `std::net::IpAddr` unstable const under the `const_ip` feature: - `is_unspecified` - `is_loopback` - `is_global` - `is_multicast` Also adds a test for these methods in a const context. Possible because these methods delegate to the inner `Ipv4Addr` or `Ipv6Addr`, which were made const ([PR#76205](rust-lang#76142) and [PR#76206](rust-lang#76206)), and the recent stabilization of const control flow. Part of rust-lang#76205 r? @ecstatic-morse

Stabilize `IpAddr::is_ipv4` and `is_ipv6` as const Insta-stabilize the methods `is_ipv4` and `is_ipv6` of `std::net::IpAddr` as const, in the same way as [PR#76198](rust-lang#76198). Possible because of the recent stabilization of const control flow. Part of rust-lang#76225 and rust-lang#76205.

Stabilize all stable methods of `Ipv4Addr`, `Ipv6Addr` and `IpAddr` as const This PR stabilizes all currently stable methods of `Ipv4Addr`, `Ipv6Addr` and `IpAddr` as const. Tracking issue: rust-lang#76205 `Ipv4Addr` (`const_ipv4`): - `octets` - `is_loopback` - `is_private` - `is_link_local` - `is_multicast` - `is_broadcast` - `is_docmentation` - `to_ipv6_compatible` - `to_ipv6_mapped` `Ipv6Addr` (`const_ipv6`): - `segments` - `is_unspecified` - `is_loopback` - `is_multicast` - `to_ipv4` `IpAddr` (`const_ip`): - `is_unspecified` - `is_loopback` - `is_multicast` ## Motivation The ip methods seem like prime candidates to be made const: their behavior is defined by an external spec, and based solely on the byte contents of an address. These methods have been made unstable const in the beginning of September, after the necessary const integer arithmetic was stabilized. There is currently a PR open (rust-lang#78802) to change the internal representation of `IpAddr{4,6}` from `libc` types to a byte array. This does not have any impact on the constness of the methods. ## Implementation Most of the stabilizations are straightforward, with the exception of `Ipv6Addr::segments`, which uses the unstable feature `const_fn_transmute`. The code could be rewritten to equivalent stable code, but this leads to worse code generation (rust-lang#75085). This is why `segments` gets marked with `#[rustc_allow_const_fn_unstable(const_fn_transmute)]`, like the already const-stable `Ipv6Addr::new`, the justification being that a const-stable alternative implementation exists rust-lang#76206 (comment). ## Future posibilities This PR const-stabilizes all currently stable ip methods, however there are also a number of unstable methods under the `ip` feature (rust-lang#27709). These methods are already unstable const. There is a PR open (rust-lang#76098) to stabilize those methods, which could include const-stabilization. However, stabilizing those methods as const is dependent on `Ipv4Addr::octets` and `Ipv6Addr::segments` (covered by this PR).

Jirubizu · 2023-08-22T13:48:39Z

has there been any updates on this?

Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable, as well as const stabilize `Ipv6Addr::to_ipv4_mapped`. Newly stable API: impl IpAddr { // Now stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; } impl Ipv6Addr { // Now stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; // Already stable, this makes it const stable under // `const_ipv6_to_ipv4_mapped const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> } These stabilize a subset of the following tracking issues: - rust-lang#27709 - rust-lang#76205

Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable, as well as const stabilize `Ipv6Addr::to_ipv4_mapped`. Newly stable API: impl IpAddr { // Now stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; } impl Ipv6Addr { // Now stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; // Already stable, this makes it const stable under // `const_ipv6_to_ipv4_mapped` const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> } These stabilize a subset of the following tracking issues: - rust-lang#27709 - rust-lang#76205

Stabilize `{IpAddr, Ipv6Addr}::to_canonical` Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`. Newly stable API: ```rust impl IpAddr { // Newly stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; } impl Ipv6Addr { // Newly stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; // Already stable, this makes it const stable under // `const_ipv6_to_ipv4_mapped` const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> } ``` These stabilize a subset of the following tracking issues: - rust-lang#27709 - rust-lang#76205 Stabilization of all methods under the `ip` gate was attempted once at rust-lang#66584 then again at rust-lang#76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward. I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in rust-lang#87708 cc implementor `@the8472` r? libs-api `@rustbot` label +T-libs-api +needs-fcp

Stabilize `{IpAddr, Ipv6Addr}::to_canonical` Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`. Newly stable API: ```rust impl IpAddr { // Newly stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; } impl Ipv6Addr { // Newly stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; // Already stable, this makes it const stable under // `const_ipv6_to_ipv4_mapped` const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> } ``` These stabilize a subset of the following tracking issues: - rust-lang#27709 - rust-lang#76205 Stabilization of all methods under the `ip` gate was attempted once at rust-lang#66584 then again at rust-lang#76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward. I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in rust-lang#87708 cc implementor ``@the8472`` r? libs-api ``@rustbot`` label +T-libs-api +needs-fcp

Rollup merge of rust-lang#115955 - tgross35:ip-to-canonical, r=dtolnay Stabilize `{IpAddr, Ipv6Addr}::to_canonical` Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`. Newly stable API: ```rust impl IpAddr { // Newly stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; } impl Ipv6Addr { // Newly stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; // Already stable, this makes it const stable under // `const_ipv6_to_ipv4_mapped` const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> } ``` These stabilize a subset of the following tracking issues: - rust-lang#27709 - rust-lang#76205 Stabilization of all methods under the `ip` gate was attempted once at rust-lang#66584 then again at rust-lang#76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward. I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in rust-lang#87708 cc implementor ``@the8472`` r? libs-api ``@rustbot`` label +T-libs-api +needs-fcp

Dylan-DPC · 2024-01-03T19:11:17Z

Closing this as it these have been stabilised by #79342. If any are missing it is better to add them in a new tracking issue for visibility sake.

RalfJung · 2024-10-12T17:11:40Z

This should not have been closed, there's still a bunch of functions referencing this as their tracking issue.

#131616 fixes that.

merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate rust-lang#76205 has been closed a while ago, but there are still some functions that reference it. Those functions are all unstable *and* const-unstable. There's no good reason to use a separate feature gate for their const-stability, so this PR moves their const-stability under the same gate as their regular stability, and therefore removes the remaining references to rust-lang#76205.

core/net: add Ipv[46]Addr::from_octets, Ipv6Addr::from_segments. Adds: - `Ipv4Address::from_octets([u8;4])` - `Ipv6Address::from_octets([u8;16])` - `Ipv6Address::from_segments([u16;8])` equivalent to the existing `From` impls. Advantages: - Consistent with `to_bits, from_bits`. - More discoverable than the `From` impls. - Helps with type inference: it's common to want to convert byte slices to IP addrs. If you try this ```rust fn foo(x: &[u8]) -> Ipv4Addr { Ipv4Addr::from(foo.try_into().unwrap()) } ``` it [doesn't work](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0e2873312de275a58fa6e33d1b213bec). You have to write `Ipv4Addr::from(<[u8;4]>::try_from(x).unwrap())` instead, which is not great. With `from_octets` it is able to infer the right types. Found this while porting [smoltcp](https://github.com/smoltcp-rs/smoltcp/) from its own IP address types to the `core::net` types. ~~Tracking issues rust-lang#27709 rust-lang#76205~~ Tracking issue: rust-lang#131360

merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate rust-lang#76205 has been closed a while ago, but there are still some functions that reference it. Those functions are all unstable *and* const-unstable. There's no good reason to use a separate feature gate for their const-stability, so this PR moves their const-stability under the same gate as their regular stability, and therefore removes the remaining references to rust-lang#76205.

core/net: add Ipv[46]Addr::from_octets, Ipv6Addr::from_segments. Adds: - `Ipv4Address::from_octets([u8;4])` - `Ipv6Address::from_octets([u8;16])` - `Ipv6Address::from_segments([u16;8])` equivalent to the existing `From` impls. Advantages: - Consistent with `to_bits, from_bits`. - More discoverable than the `From` impls. - Helps with type inference: it's common to want to convert byte slices to IP addrs. If you try this ```rust fn foo(x: &[u8]) -> Ipv4Addr { Ipv4Addr::from(foo.try_into().unwrap()) } ``` it [doesn't work](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0e2873312de275a58fa6e33d1b213bec). You have to write `Ipv4Addr::from(<[u8;4]>::try_from(x).unwrap())` instead, which is not great. With `from_octets` it is able to infer the right types. Found this while porting [smoltcp](https://github.com/smoltcp-rs/smoltcp/) from its own IP address types to the `core::net` types. ~~Tracking issues rust-lang#27709 rust-lang#76205~~ Tracking issue: rust-lang#131360

merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate rust-lang#76205 has been closed a while ago, but there are still some functions that reference it. Those functions are all unstable *and* const-unstable. There's no good reason to use a separate feature gate for their const-stability, so this PR moves their const-stability under the same gate as their regular stability, and therefore removes the remaining references to rust-lang#76205.

Rollup merge of rust-lang#131616 - RalfJung:const_ip, r=tgross35 merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate rust-lang#76205 has been closed a while ago, but there are still some functions that reference it. Those functions are all unstable *and* const-unstable. There's no good reason to use a separate feature gate for their const-stability, so this PR moves their const-stability under the same gate as their regular stability, and therefore removes the remaining references to rust-lang#76205.

Rollup merge of rust-lang#130629 - Dirbaio:net-from-octets, r=tgross35 core/net: add Ipv[46]Addr::from_octets, Ipv6Addr::from_segments. Adds: - `Ipv4Address::from_octets([u8;4])` - `Ipv6Address::from_octets([u8;16])` - `Ipv6Address::from_segments([u16;8])` equivalent to the existing `From` impls. Advantages: - Consistent with `to_bits, from_bits`. - More discoverable than the `From` impls. - Helps with type inference: it's common to want to convert byte slices to IP addrs. If you try this ```rust fn foo(x: &[u8]) -> Ipv4Addr { Ipv4Addr::from(foo.try_into().unwrap()) } ``` it [doesn't work](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0e2873312de275a58fa6e33d1b213bec). You have to write `Ipv4Addr::from(<[u8;4]>::try_from(x).unwrap())` instead, which is not great. With `from_octets` it is able to infer the right types. Found this while porting [smoltcp](https://github.com/smoltcp-rs/smoltcp/) from its own IP address types to the `core::net` types. ~~Tracking issues rust-lang#27709 rust-lang#76205~~ Tracking issue: rust-lang#131360

merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate rust-lang/rust#76205 has been closed a while ago, but there are still some functions that reference it. Those functions are all unstable *and* const-unstable. There's no good reason to use a separate feature gate for their const-stability, so this PR moves their const-stability under the same gate as their regular stability, and therefore removes the remaining references to rust-lang/rust#76205.

jonas-schievink added A-const-fn C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Sep 1, 2020

This was referenced Sep 1, 2020

Make all methods of std::net::Ipv6Addr const #76206

Merged

Make all methods of std::net::Ipv4Addr const #76142

Merged

Stabilize IpAddr::is_ipv4 and is_ipv6 as const #76226

Merged

CDirkx mentioned this issue Sep 3, 2020

Make delegation methods of std::net::IpAddr unstably const #76304

Merged

CDirkx mentioned this issue Nov 23, 2020

Stabilize all stable methods of Ipv4Addr, Ipv6Addr and IpAddr as const #79342

Merged

jplatte mentioned this issue Aug 2, 2021

Data to add jplatte/caniuse.rs#16

Open

65 tasks

massa-bot mentioned this issue Nov 8, 2021

Ip address validation massalabs/massa#2

Closed

tgross35 mentioned this issue Sep 19, 2023

Stabilize {IpAddr, Ipv6Addr}::to_canonical #115955

Merged

jstasiak mentioned this issue Dec 18, 2023

Add Ipv6Addr::is_ipv4_mapped #119081

Merged

Dylan-DPC closed this as completed Jan 3, 2024

Dirbaio mentioned this issue Sep 20, 2024

core/net: add Ipv[46]Addr::from_octets, Ipv6Addr::from_segments. #130629

Merged

RalfJung mentioned this issue Oct 12, 2024

merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate #131616

Merged

RalfJung added the A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) label Dec 1, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Constify `std::net::IpAddr`, `Ipv4Addr`, and `Ipv6Addr` #76205

Constify `std::net::IpAddr`, `Ipv4Addr`, and `Ipv6Addr` #76205

CDirkx commented Sep 1, 2020 •

edited

Loading

Jirubizu commented Aug 22, 2023

Dylan-DPC commented Jan 3, 2024

RalfJung commented Oct 12, 2024

Constify std::net::IpAddr, Ipv4Addr, and Ipv6Addr #76205

Constify std::net::IpAddr, Ipv4Addr, and Ipv6Addr #76205

Comments

CDirkx commented Sep 1, 2020 • edited Loading

Ipv4Addr

Ipv6Addr

IpAddr

Jirubizu commented Aug 22, 2023

Dylan-DPC commented Jan 3, 2024

RalfJung commented Oct 12, 2024

Constify `std::net::IpAddr`, `Ipv4Addr`, and `Ipv6Addr` #76205

Constify `std::net::IpAddr`, `Ipv4Addr`, and `Ipv6Addr` #76205

CDirkx commented Sep 1, 2020 •

edited

Loading

`Ipv4Addr`

`Ipv6Addr`

`IpAddr`