[API Proposal]: EqualityComparer.Create from selecting a key property

[weitzhandler]

Background and motivation

In continuation of #24460 which is so useful - thanks! it would also be great if we could create an EqualityComparer<T> from selecting which property will be used for the comparison.

API Proposal

namespace System.Collections.Generic
{
+    public static EqualityComparer<T> Create<TKey>(
+        Func<T?, TKey?> keySelector, 
+        IEqualityComparer<Tkey>? keyComparer = null) 
+    {
+        ArgumentNullException.ThrowIfNull(keySelector);
+
+        keyComparer ??= EqualityComparer<TKey>.Default;
+
+        return Create(
+            equals: (itemX, itemY) =>
+                keyComparer.Equals(keySelector(itemX), keySelector(itemY)),
+            getHashCode: item => keyComparer.GetHashCode(keySelector(item)!));
+    }
}

API Usage

record Item(string Path, HighlightType Highlight); 

// default implementation should be compare all props
var regular = new HashSet<Item>();

// use 'Path' property to check equality and create hashcode, specifying a hash code for key
var set1 = new HashSet<Item>(EqualityComparer<Item>.Create(item => item.Path));

// use 'Path' property to check equality and create hashcode, specifying a hash code for key
var comparer = EqualityComparer<Item>.Create(item => item.Path), StringComparer.OrdinalIgnoreCase); 
var set2 = new HashSet<Item>(comparer);

Alternative Designs

No response

Risks

No response

[dotnet-policy-service]

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

[stephentoub]

(EqualityComparer can't and won't depend on Expression.)

[eiriktsarpalis]

Shouldn't this also take an optional IEqualityComparer<TKey>? Seems useful enough, although I the name needs a bit of work.

[weitzhandler]

(EqualityComparer can't and won't depend on Expression.)

100%. I've updated my post.

Shouldn't this also take an optional IEqualityComparer<TKey>?

Wouldn't that defy the whole purpose of this request which is to reduce boilerplate code? If one needs to specifiy a new comparer they might as well create one from scratch, no?

[eiriktsarpalis]

Shouldn't this also take an optional IEqualityComparer<TKey>?

Wouldn't that defy the whole purpose of this request which is to reduce boilerplate code? If one needs to specifiy a new comparer they might as well create one from scratch, no?

Probably true for the 90% case but it's useful if you have a comparer for the key type handy, e.g. StringComparer.OrdinalIgnoreCase. Plus, it's the convention we've been following in all the LINQ -By methods and has no usability impact on users not needing to explicitly specify a comparer.