From ef4de7dff3eecf2788da0afca862f7a08ec1b910 Mon Sep 17 00:00:00 2001 From: Matt Horn Date: Wed, 6 Jul 2016 01:47:08 -0600 Subject: [PATCH 1/3] Propose RFC for IpAddr common methods --- text/0000-ipaddr-common-methods.md | 60 ++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 text/0000-ipaddr-common-methods.md diff --git a/text/0000-ipaddr-common-methods.md b/text/0000-ipaddr-common-methods.md new file mode 100644 index 00000000000..94dcb6fd899 --- /dev/null +++ b/text/0000-ipaddr-common-methods.md @@ -0,0 +1,60 @@ +- Feature Name: ipaddr-common-methods +- Start Date: 2016-07-06 +- RFC PR: (leave this empty) +- Rust Issue: (leave this empty) + +# Summary +[summary]: #summary + +As of Rust v1.7.0, net::Ipv4Addr and net::Ipv6Addr both expose `is_loopback()` and `is_multicast()`. +net::IpAddr should expose those directly rather than requiring a redundant `match`. +This should carry forward as [more methods are stabilized](https://github.com/rust-lang/rust/issues/27709). + +# Motivation +[motivation]: #motivation + +If I have an IpAddr and I want to test whether or not it is a loopback address, I do not need or want to know +if it is v4 or v6. As of Rust v1.7.0, testing if an IpAddr `addr` is a loopback address looks like this: +``` rust +match addr { + IpAddr::V4(v4addr) => v4addr.is_loopback(), + IpAddr::V6(v6addr) => v6addr.is_loopback(), +} +``` +If this RFC is adopted, this would become simply +``` rust +addr.is_loopback() +``` +which is much simpler. + +Additionally, net::SocketAddr.ip() and .port() do the same thing elsewhere in the standard library. + +# Detailed design +[design]: #detailed-design + +Since `is_loopback()` and `is_multicast()` are stable as of Rust v1.7.0 in both +[net::Ipv4Addr](https://doc.rust-lang.org/std/net/struct.Ipv4Addr.html) and +[net::Ipv6Addr](https://doc.rust-lang.org/std/net/struct.Ipv6Addr.html), +it seems natural to add those methods, and any others that are shared and stable, to +[net::IpAddr](https://doc.rust-lang.org/std/net/enum.IpAddr.html). + +These implementations would be written as `match`es like the one given above, similarly to +[the implementation of net::SocketAddr.ip()](https://github.com/rust-lang/rust/blob/master/src/libstd/net/addr.rs#L63-68), +which is a method that seems to exist for the same reason. + +# Drawbacks +[drawbacks]: #drawbacks + +This makes the standard library slightly larger and increases overhead in changes to Ipv4Addr and Ipv6Addr +(since newly stable methods in both structs would be added to IpAddr as well). + +# Alternatives +[alternatives]: #alternatives + +This RFC does not make anything new possible. It simply makes something slightly easier. +As such, to simply leave things as they are would be the primary alternative. + +# Unresolved questions +[unresolved]: #unresolved-questions + +Was this a deliberate omission or just something nobody asked for yet? From 18ae747e64ecf66606c18d8d7ecbff3426ae5831 Mon Sep 17 00:00:00 2001 From: Matt Horn Date: Wed, 6 Jul 2016 11:26:29 -0600 Subject: [PATCH 2/3] Add method signatures to detailed design section per https://github.com/rust-lang/rfcs/pull/1668#issuecomment-230840151 --- text/0000-ipaddr-common-methods.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/text/0000-ipaddr-common-methods.md b/text/0000-ipaddr-common-methods.md index 94dcb6fd899..fbb9d10dd96 100644 --- a/text/0000-ipaddr-common-methods.md +++ b/text/0000-ipaddr-common-methods.md @@ -42,6 +42,14 @@ These implementations would be written as `match`es like the one given above, si [the implementation of net::SocketAddr.ip()](https://github.com/rust-lang/rust/blob/master/src/libstd/net/addr.rs#L63-68), which is a method that seems to exist for the same reason. +The method signatures should be as follows: +``` rust +impl IpAddr { + fn is_loopback(&self) -> bool { ... } + fn is_multicast(&self) -> bool { ... } +} +``` + # Drawbacks [drawbacks]: #drawbacks From 17b5410bd22235ed3c36a72760a7a393b438731c Mon Sep 17 00:00:00 2001 From: Matt Horn Date: Wed, 6 Jul 2016 12:11:46 -0600 Subject: [PATCH 3/3] Add unstable shared methods per https://github.com/rust-lang/rfcs/pull/1668#issuecomment-230855352 --- text/0000-ipaddr-common-methods.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/text/0000-ipaddr-common-methods.md b/text/0000-ipaddr-common-methods.md index fbb9d10dd96..3cdfb044cba 100644 --- a/text/0000-ipaddr-common-methods.md +++ b/text/0000-ipaddr-common-methods.md @@ -6,9 +6,8 @@ # Summary [summary]: #summary -As of Rust v1.7.0, net::Ipv4Addr and net::Ipv6Addr both expose `is_loopback()` and `is_multicast()`. +net::Ipv4Addr and net::Ipv6Addr both expose methods like `is_loopback()` and `is_multicast()`. net::IpAddr should expose those directly rather than requiring a redundant `match`. -This should carry forward as [more methods are stabilized](https://github.com/rust-lang/rust/issues/27709). # Motivation [motivation]: #motivation @@ -32,10 +31,10 @@ Additionally, net::SocketAddr.ip() and .port() do the same thing elsewhere in th # Detailed design [design]: #detailed-design -Since `is_loopback()` and `is_multicast()` are stable as of Rust v1.7.0 in both +Since several methods, like `is_loopback()` and `is_multicast()`, exist in both [net::Ipv4Addr](https://doc.rust-lang.org/std/net/struct.Ipv4Addr.html) and [net::Ipv6Addr](https://doc.rust-lang.org/std/net/struct.Ipv6Addr.html), -it seems natural to add those methods, and any others that are shared and stable, to +it seems natural to add those methods to [net::IpAddr](https://doc.rust-lang.org/std/net/enum.IpAddr.html). These implementations would be written as `match`es like the one given above, similarly to @@ -45,8 +44,11 @@ which is a method that seems to exist for the same reason. The method signatures should be as follows: ``` rust impl IpAddr { + fn is_unspecified(&self) -> bool { ... } fn is_loopback(&self) -> bool { ... } + fn is_global(&self) -> bool { ... } fn is_multicast(&self) -> bool { ... } + fn is_documentation(&self) -> bool { ... } } ``` @@ -54,7 +56,7 @@ impl IpAddr { [drawbacks]: #drawbacks This makes the standard library slightly larger and increases overhead in changes to Ipv4Addr and Ipv6Addr -(since newly stable methods in both structs would be added to IpAddr as well). +(since new methods in both structs would be added to IpAddr as well). # Alternatives [alternatives]: #alternatives @@ -65,4 +67,4 @@ As such, to simply leave things as they are would be the primary alternative. # Unresolved questions [unresolved]: #unresolved-questions -Was this a deliberate omission or just something nobody asked for yet? +Are Ipv4Addr.is_link_local() and Ipv6Addr.is_unicast_link_local() the same? If so, which name should be used in IpAddr?