[API Proposal]: Add IComparable to IPAddress and PhysicalAddress classes

[maknapp]

Background and motivation

I am suggesting this mainly due to changes in efcore (see dotnet/efcore#23775). In short, efcore v5+ requires unique indexes to implement IComparable, preventing IPAddress and PhysicalAddress from being used as unique indexes. This is blocking me from updating some projects beyond .NET Core 3.1.

This has been suggested before for IPAddress (see #28964). A quick search shows many people looking to sort IPAddress and resorting to System.Version.Parse on the string, showing it is a fairly common need. The need for PhysicalAddress sorting seems less common.

API Proposal

namespace System.Net.NetworkInformation
{
    public class PhysicalAddress : IComparable<PhysicalAddress>
    {
        public int CompareTo(PhysicalAddress other);
    }
}

namespace System.Net
{
    public class IPAddress : IComparable<IPAddress>
    {
        public int CompareTo(IPAddress other);
    }
}

API Usage

var x = new[]
{
    "192.168.0.1",
    "0:0:0:0:0:FFFF:C0A8:0018",
    "192.168.0.1",
    "192.168.0.24",
    "2001:0db8:85a3:0000:0000:8a2e:0370:7334",
    "::f",
    "0:0:0:0:0:FFFF:0C05:2842",
    "192.168.2.1",
    "192.168.0.10",
    "192.168.0.1",
    "2001:0db8:85a3:0000:0000:8a2e:0370:7334"
};

var y = x.Select(x => IPAddress.Parse(x)).OrderBy(x => x);

foreach(var item in y)
{
    Console.WriteLine(item);
}

// 192.168.0.1
// 192.168.0.1
// 192.168.0.1
// 192.168.0.10
// 192.168.0.24
// 192.168.2.1
// ::f
// ::ffff:12.5.40.66
// ::ffff:192.168.0.24
// 2001:db8:85a3::8a2e:370:7334
// 2001:db8:85a3::8a2e:370:7334

Risks

I do not see any breaking changes or changes in performance.

[huoyaoyuan]

Generally the BCL shouldn't be modified to fit EF Core. They should fit BCL.

Does specification of network addresses mention sorting?

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

I am suggesting this mainly due to changes in efcore (see dotnet/efcore#23775). In short, efcore v5+ requires unique indexes to implement IComparable, preventing IPAddress and PhysicalAddress from being used as unique indexes. This is blocking me from updating some projects beyond .NET Core 3.1.

This has been suggested before for IPAddress (see #28964). A quick search shows many people looking to sort IPAddress and resorting to System.Version.Parse on the string, showing it is a fairly common need. The need for PhysicalAddress sorting seems less common.

API Proposal

namespace System.Net.NetworkInformation
{
    public class PhysicalAddress : IComparable<PhysicalAddress>
    {
        public int CompareTo(PhysicalAddress other);
    }
}

namespace System.Net
{
    public class IPAddress : IComparable<IPAddress>
    {
        public int CompareTo(IPAddress other);
    }
}

API Usage

var x = new[]
{
    "192.168.0.1",
    "0:0:0:0:0:FFFF:C0A8:0018",
    "192.168.0.1",
    "192.168.0.24",
    "2001:0db8:85a3:0000:0000:8a2e:0370:7334",
    "::f",
    "0:0:0:0:0:FFFF:0C05:2842",
    "192.168.2.1",
    "192.168.0.10",
    "192.168.0.1",
    "2001:0db8:85a3:0000:0000:8a2e:0370:7334"
};

var y = x.Select(x => IPAddress.Parse(x)).OrderBy(x => x);

foreach(var item in y)
{
    Console.WriteLine(item);
}

// 192.168.0.1
// 192.168.0.1
// 192.168.0.1
// 192.168.0.10
// 192.168.0.24
// 192.168.2.1
// ::f
// ::ffff:12.5.40.66
// ::ffff:192.168.0.24
// 2001:db8:85a3::8a2e:370:7334
// 2001:db8:85a3::8a2e:370:7334

Risks

I do not see any breaking changes or changes in performance.

Author:	maknapp
Assignees:	-
Labels:	api-suggestion, area-System.Net, untriaged
Milestone:	-

[geoffkizer]

It seems reasonable to add IEquatable<T> in these cases, though in general that shouldn't be necessary -- generic collection types don't require this in general.

It seems really weird to add IComparable<T> in these cases, since there is no well defined ordering and so whatever we did would be arbitrary.

[ManickaP]

Triage: IComparable doesn't make sense here, we shouldn't introduce a new interface to a type to solve a particular EF Core issue. We might consider IEquatable in a new issue.