Skip to content
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

Equals/GetHashCode for UnixDomainSocketEndPoint #69488

Closed
sakno opened this issue May 18, 2022 · 5 comments · Fixed by #69722
Closed

Equals/GetHashCode for UnixDomainSocketEndPoint #69488

sakno opened this issue May 18, 2022 · 5 comments · Fixed by #69722
Milestone

Comments

@sakno
Copy link
Contributor

sakno commented May 18, 2022

Background and motivation

My network framework uses EndPoint class as abstraction layer to represent the peer address. It is easy to determine whether the two endpoints represent the same address using Equals method. However, UnixDomainSocketEndPoint doesn't override necessary methods in contrast to IPEndPoint and DnsEndPoint.

API Proposal

namespace System.Net.Sockets;

public sealed class UnixDomainSocketEndPoint : EndPoint
{
  public override bool Equals(object? other);
  public override int GetHashCode();
}

API Usage

var set = new HashSet();

set.Add(new UnixDomainSocketEndPoint("@abstract"));
set.Contains(new UnixDomainSocketEndPoint("@abstract"));

Alternative Designs

Implement custom equality logic:

static bool EndPointsAreEqual(EndPoint x, EndPoint y)
{
  if (x is UnixDomainSocketEndPoint uds1)
    return y is UnixDomainSocketEndPoint uds2 && string.Equals(uds1.ToString(), uds2.ToString(), StringComparison.Ordinal);

  return object.Equals(x, y);
}

Risks

Breaks behavior of default implementation of Equals and GetHashCode.

@sakno sakno added the api-suggestion Early API idea and discussion, it is NOT ready for implementation label May 18, 2022
@ghost ghost added the untriaged New issue has not been triaged by the area owner label May 18, 2022
@ghost
Copy link

ghost commented May 18, 2022

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

Issue Details

Background and motivation

My network framework uses EndPoint class as abstraction layer to represent the peer address. It is easy to determine whether the two endpoints represent the same address using Equals method. However, UnixDomainSocketEndPoint doesn't override necessary methods in contrast to IPEndPoint and DnsEndPoint.

API Proposal

namespace System.Net.Sockets;

public sealed class UnixDomainSocketEndPoint : EndPoint
{
  public override bool Equals(object? other);
  public override int GetHashCode();
}

API Usage

var set = new HashSet();

set.Add(new UnixDomainSocketEndPoint("@abstract"));
set.Contains(new UnixDomainSocketEndPoint("@abstract"));

Alternative Designs

Implement custom equality logic:

static bool EndPointsAreEqual(EndPoint x, EndPoint y)
{
  if (x is UnixDomainSocketEndPoint uds1)
    return y is UnixDomainSocketEndPoint uds2 && string.Equals(uds1.ToString(), uds2.ToString(), StringComparison.Ordinal);

  return object.Equals(x, y);
}

Risks

Breaks behavior of default implementation of Equals and GetHashCode.

Author: sakno
Assignees: -
Labels:

api-suggestion, area-System.Net, untriaged

Milestone: -

@stephentoub
Copy link
Member

Given that both IPEndPoint and DnsEndPoint override these, it's reasonable for UnixDomainSocketEndPoint to as well. I don't think this really needs to be considered an API proposal. Technically it could break someone relying on Equals providing reference equality, but the chances of that are slim, especially since that's not what it means generally when using the base EndPoint.

@stephentoub stephentoub removed the api-suggestion Early API idea and discussion, it is NOT ready for implementation label May 18, 2022
@sakno
Copy link
Contributor Author

sakno commented May 18, 2022

@stephentoub , if so, I'm ready to make a PR.

@sakno sakno changed the title [API Proposal]: Equals/GetHashCode for UnixDomainSocketEndPoint Equals/GetHashCode for UnixDomainSocketEndPoint May 18, 2022
@CarnaViire
Copy link
Member

Triage: that makes sense; we would gladly accept the contribution @sakno
Moving to Future as it's not a priority

@CarnaViire CarnaViire removed the untriaged New issue has not been triaged by the area owner label May 19, 2022
@CarnaViire CarnaViire added this to the Future milestone May 19, 2022
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label May 24, 2022
@sakno
Copy link
Contributor Author

sakno commented May 25, 2022

@CarnaViire , PR is ready for review.

@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jun 8, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Jul 8, 2022
@karelz karelz modified the milestones: Future, 7.0.0 Jul 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants