There's some confusion around serialization/deserialization, added some test cases which can serve as an example.

If we wanted to change how we go from string/to json we can implement the Serialize and Deserialize trait. I can see how some people expect it to deserialize and serialize from a single string and not an object.

Edit: In https://github.com/achanda/ipnetwork/issues/73, we now want to serialize/deserialize from a string, Serialize and Deserialize traits are implemented in this PR

The serde support is not optional though someone might not need it. Serde (and especially serde-derive) is somewhat heavy dependency and it is quite common to have serde as a feature flag on many crates.

Would it be OK if I add the support?

For example, if you get a JSON payload with network addresses like "10.0.0.0/24" or "fd00::/64" it won't be deserialised to IpNetwork. A quick look at the code confirms this. derive(Serialize, Deserialize) doesn't cut it here. Those traits will need to be implemented manually.

an_array.into_iter() currently just works because of the autoref feature, which then calls <[T] as IntoIterator>::into_iter. But in the future, arrays will implement IntoIterator, too. In order to avoid problems in the future, the call is replaced by iter() which is shorter and more explicit.

A crater run showed that your crate is affected by a potential future change. See https://github.com/rust-lang/rust/pull/65819 for more information.

https://docs.rs/ipnetwork/0.13.0/ipnetwork/struct.Ipv4Network.html#method.size

Is it safe to change this method to return a u32 since IPv4 networks can never be bigger than 32 bits? Would you mind if I sent a PR that introduces a breaking change to this API? It would help me cut a cast out of my code.

I combined three things in one PR here. Just tell me if you want me to split it up and/or if you don't want some of it.

• fixed a bug in Ipv4Network::mask that resulted in a shift error when using /32 networks.
• Added size and nth methods to Ipv4Network since I needed them. I hope you will find it useful.
• Remade the public API so that any creation of any of the three network types return a Result<Ip*Network, IpNetworkError> instead of the network directly. The reason is that all of them allow inputs that can be invalid. This is a pretty large change so I'm not sure if you want it or not. If merged, this probably need a version bump to 0.7.0.

Currently the Ipv4Network can be parsed from ip/prefix representation (eg. 192.168.2.1/24), but the older ip/mask (192.168.2.1/255.255.255.0) is rejected. Would it make sense to add such support too?

This adds From traits so one can conveniently convert an IpAddr to an IpNetwork containing a single address without checking if it's an IPv4 or IPv6 address.

The main file, lib.rs is growing quite large. A lot of IPv4 and IPv6 stuff is more or less interleaved. I think this library would benefit from being split up into smaller files. Do you agree @achanda ?

If so, how do we do this? Simplest solution would be to just create ipv4.rs and ipv6.rs and move the respective code (and tests) into those. How about the common stuff? Some stuff is shared between the two versions and the more code they can share the better. Just put it in a common.rs? lib.rs can just reexport everything so the public API is the same as today.

I can start working on this, but I want to discuss what you think first.

Possible to get the size of the network and the Nth host address from it.

Designed slightly different than in my previous PR where I included three things in one. Now I regard a /32 net as having size 0 instead of 1 as in the previous version. This should be more correct.

Work in progress, not ready to merge. Just want to get feedback at this stage.

I need to parse CIDRs from strings, do you think that's a good addition to the library?

As far as I can tell, the public API of this crate has stayed backwards compatible for quite a few versions already. This means that releasing a 1.0 version in the current form would allow to add new features (in 1.x) versions without sacrificing backwards compatibility.

This, in turn, would make it easier for crates such as diesel and sqlx to keep an up to date ipnetwork dependency without having to release a new version themselves whenever a new ipnetwork version is released.

Is there something preventing the release of a 1.0 version?

Hi

use ipnetwork::Ipv4Network;
let net: Ipv4Network = "10.1.0.0/16".parse().unwrap();
let net2: Ipv4Network = "10.1.0.0/15".parse().unwrap();
println!("{:?} {} {}", net2, net.is_supernet_of(net2),
    net.is_supernet_of(Ipv4Network::new(net2.network(), net2.prefix()).unwrap()));

Output: Ipv4Network { addr: 10.1.0.0, prefix: 15 } true false

So, is_supernet_of accidentally thinks that /16 is a supernet of /15 if network address is the same.

PS: Prefix "X/Y" consists of network address X and bits Y. So, function prefix which return bits confuses any network engineer.

nth method is implemented for Ipv4Network but not for Ipv6Network. Is it due to some fundamental difference between IP4/IP6 neworks or just forgotten?

When creating an IP network, the network address's device bits should be resets to zero and then save into the struct.

For example, I believe the following two networks should be considered the same: 8.8.8.0/24 and 8.8.8.1/24. But when the resulting IpNetwork are different, and the to_string results are also different.