Change:
Feature gate: This is a tracking issue for RFC , providing networking types in : , , , , , , and . [x] Implementation: [x] Final comment period (FCP)[^1] [x] Stabilization PR: [^1]: https://std-dev-
I guess there's nothing left to do. Can this feature now move to the the FCP?
Can this be stabilized before  ( implements )?
I believe so. Nothing in ipaddr points or uses core::error::Error: (master) The only impl Error is in Parser and I guess it needs to be featured gated:
You can't feature gate a trait implementation. The question would be if it's possible to refer to any of the methods on the error types without having to activate the feature. I believe not, since you would have to in order to bring the methods into scope.
Thanks for the explanation and yes, I agree that it can't be stabilised before Error then.
I disagree, this feature can be specialized before . Nothing will change for users, and users will merely not be able to use the impl. This is just like all existing errors in , eg (which is arguably stable):
Ping could this go into FCP?
Yes, please.
nominate libs
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
maybe? Would like to get some confirmation that this is on some list somewhere for discussion.
I've the nomination label so it'll be discussed in a libs-api meeting, though it's possible a libs-api member may decide to remove the label and just fcp it. It'd likely be helpful if someone could provide a summary of the current state of things and why this is ready for stabilization.
I'm not claiming this bears enough weight to stabilize but I just allowed in a small library that used address types and it went completely smooth.
Starting FCP for stabilization. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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 for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
I pushed a stabilization PR:

Discussion:
//! * [`SocketAddr`] represents socket addresses of either IPv4 or IPv6; [`SocketAddrV4`] //!   and [`SocketAddrV6`] are respectively IPv4 and IPv6 socket addresses <del> #![unstable(feature = "ip_in_core", issue = "108443")] </del> <ins> #![stable(feature = "ip_in_core", since = "CURRENT_RUSTC_VERSION")] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub use self::ip_addr::{IpAddr, Ipv4Addr, Ipv6Addr, Ipv6MulticastScope};

#![feature(slice_internals)] #![feature(slice_partition_dedup)] #![feature(ip)] <del> #![feature(ip_in_core)] </del> #![feature(iter_advance_by)] #![feature(iter_array_chunks)] #![feature(iter_collect_into)]

#![feature(hasher_prefixfree_extras)] #![feature(hashmap_internals)] #![feature(ip)] <del> #![feature(ip_in_core)] </del> #![feature(maybe_uninit_slice)] #![feature(maybe_uninit_uninit_array)] #![feature(maybe_uninit_write_slice)]