-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ipv4Addr and Ipv6Addr convenience constructors. #44395
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @BurntSushi (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
src/libstd/net/ip.rs
Outdated
assert_eq!(Ipv6Addr::unspecified(), Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 0)); | ||
assert!(Ipv6Addr::unspecified().is_unspecified()); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trim the trailing whitespace.
src/libstd/net/ip.rs
Outdated
/// use std::net::Ipv4Addr; | ||
/// | ||
/// let addr = Ipv4Addr::localhost(); | ||
/// assert_eq!(addr, Ipv4Addr::new(127, 0, 0, 1)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing line closing the code example:
/// ```
src/libstd/net/ip.rs
Outdated
/// use std::net::Ipv4Addr; | ||
/// | ||
/// let addr = Ipv4Addr::unspecified(); | ||
/// assert_eq!(addr, Ipv4Addr::new(0, 0, 0, 0)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing line closing the code example:
/// ```
src/libstd/net/ip.rs
Outdated
/// use std::net::Ipv6Addr; | ||
/// | ||
/// let addr = Ipv6Addr::localhost(); | ||
/// assert_eq!(addr, Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 1)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing line closing the code example:
/// ```
src/libstd/net/ip.rs
Outdated
/// use std::net::Ipv6Addr; | ||
/// | ||
/// let addr = Ipv6Addr::unspecified(); | ||
/// assert_eq!(addr, Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 0)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing line closing the code example:
/// ```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All resolved. Thanks.
/// | ||
/// # Examples | ||
/// | ||
/// ``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe you need to add # #![feature(ip)]
to this and the other new examples in order for the doc tests to work. The first #
hides the line from the docs (which you might not want to do to make it clear that it is needed for this usage).
3572665
to
8b6122f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks reasonable to me, but I think these need stability attributes, and should be unstable for now.
cc @rust-lang/libs
Looks reasonable to me as well! @jcdyer mind adding the stability attributes and filing an issue to track the stability here? |
@estebank @BurntSushi I added the unstable attributes, and created a tracking issue. I'm not entirely sure what needs to happen, but I did my best based on a quick search of other similar examples. Let me know if anything needs to be different. |
📌 Commit 9d5b0e1 has been approved by |
@bors: rollup |
Ipv4Addr and Ipv6Addr convenience constructors. Introduce convenience constructors for common types. This introduces the following constructors: * Ipv6Addr::localhost() * Ipv6Addr::unspecified() * Ipv4Addr::localhost() * Ipv4Addr::unspecified() The recently added `From` implementations were nice for avoiding the fallibility of conversions from strings like `"127.0.0.1".parse().unwrap()`, and `"::1".parse().unwrap()`, but while the Ipv4 version is roughly comparable in verbosity, the Ipv6 version lacks zero-segment elision, which makes it significantly more awkward: `[0, 0, 0, 0, 0, 0, 0, 0].into()`. While there isn't a clear way to introduce zero elision to type that can infallibly be converted into Ipv6 addresses, this PR resolves the problem for the two most commonly used addresses, which, incidentally, are the ones that suffer the most from the lack of zero-segment elision. This change is dead simple, and introduces no backwards incompatibility. See also, [this topic on the inernals board](https://internals.rust-lang.org/t/pre-rfc-convenience-ip-address-constructors/5878)
Ipv4Addr and Ipv6Addr convenience constructors. Introduce convenience constructors for common types. This introduces the following constructors: * Ipv6Addr::localhost() * Ipv6Addr::unspecified() * Ipv4Addr::localhost() * Ipv4Addr::unspecified() The recently added `From` implementations were nice for avoiding the fallibility of conversions from strings like `"127.0.0.1".parse().unwrap()`, and `"::1".parse().unwrap()`, but while the Ipv4 version is roughly comparable in verbosity, the Ipv6 version lacks zero-segment elision, which makes it significantly more awkward: `[0, 0, 0, 0, 0, 0, 0, 0].into()`. While there isn't a clear way to introduce zero elision to type that can infallibly be converted into Ipv6 addresses, this PR resolves the problem for the two most commonly used addresses, which, incidentally, are the ones that suffer the most from the lack of zero-segment elision. This change is dead simple, and introduces no backwards incompatibility. See also, [this topic on the inernals board](https://internals.rust-lang.org/t/pre-rfc-convenience-ip-address-constructors/5878)
Ipv4Addr and Ipv6Addr convenience constructors. Introduce convenience constructors for common types. This introduces the following constructors: * Ipv6Addr::localhost() * Ipv6Addr::unspecified() * Ipv4Addr::localhost() * Ipv4Addr::unspecified() The recently added `From` implementations were nice for avoiding the fallibility of conversions from strings like `"127.0.0.1".parse().unwrap()`, and `"::1".parse().unwrap()`, but while the Ipv4 version is roughly comparable in verbosity, the Ipv6 version lacks zero-segment elision, which makes it significantly more awkward: `[0, 0, 0, 0, 0, 0, 0, 0].into()`. While there isn't a clear way to introduce zero elision to type that can infallibly be converted into Ipv6 addresses, this PR resolves the problem for the two most commonly used addresses, which, incidentally, are the ones that suffer the most from the lack of zero-segment elision. This change is dead simple, and introduces no backwards incompatibility. See also, [this topic on the inernals board](https://internals.rust-lang.org/t/pre-rfc-convenience-ip-address-constructors/5878)
Introduce convenience constructors for common types.
This introduces the following constructors:
The recently added
From
implementations were nice for avoiding the fallibility of conversions from strings like"127.0.0.1".parse().unwrap()
, and"::1".parse().unwrap()
, but while the Ipv4 version is roughly comparable in verbosity, the Ipv6 version lacks zero-segment elision, which makes it significantly more awkward:[0, 0, 0, 0, 0, 0, 0, 0].into()
. While there isn't a clear way to introduce zero elision to type that can infallibly be converted into Ipv6 addresses, this PR resolves the problem for the two most commonly used addresses, which, incidentally, are the ones that suffer the most from the lack of zero-segment elision.This change is dead simple, and introduces no backwards incompatibility.
See also, this topic on the inernals board