Perché SequenceEqual accetta un compititore IEquality piuttosto che un predicato?

Question

Perché lo Enumerable.SequenceEqual prende il suo confronto come IEqualityComparer? L'algoritmo sembra non fare uso di GetHashCode. Perché non prende invece un predicato Func<TSource, TSource, bool>, simile a come First prende un Func<TSource, bool>?

Answer 1

Ora che .NET Core è open source, ho inserito questa domanda come issue su GitHub. Spero che ciò si traduca in una risposta o un miglioramento.

---

Aggiornamento - dettagli sul possibile razionale per la progettazione esistente e le sue problematiche, tratto dal problema GitHub:

IEqualityComparer, nonostante il nome, in realtà fa due cose: hash e controlla uguaglianza. L'unica differenza comportamentale tra Func<TSource, TSource, bool>Func<TSource, TSource, bool> e IEqualityComparer è IEqualityComparer ha un metodo GetHashCode. Se tutto ciò che si desidera fare è controllare l'uguaglianza di sequenza, con IEqualityComparer è necessario scrivere il codice di hashing (che può essere difficile da fare bene), anche se non sarà mai usato (ma non si può contare su non è mai stato usato perché SequenceEqual non documenta che non lo userà).

Spesso, tipi che si confronta con SequenceEqual accadrà di avere uno o più tipi IEqualityComparer compagno in modo che possano essere conservati in contenitori hash. Probabilmente, è per questo che IEqualityComparer è stato scelto come parametro. Tuttavia, ci sono anche un sacco di volte quando non c'è un IEqualityComparer e non c'è un requisito di hashing . In questi casi, dover creare una classe e implementare GetHashCode è uno spreco.

Answer 2

Sono tentato di dire "perché".

Se si guardano intorno ad altri metodi simili (come Enumerable.Distinct) prendono anche un IEqualityComparer nel sovraccarico.

Inoltre, un IEqualityComparer è il modo "corretto" per verificare se gli oggetti sono uguali. A Func<TSource, TSource, bool> non verificherebbe necessariamente l'uguaglianza, verificherebbe se gli oggetti sono abbastanza simili per il tuo uso specifico in questo momento.

Fortunatamente è abbastanza facile creare il proprio metodo di estensione. Ad esempio, MoreLinq ha un'implementazione di DistinctBy che puoi guardare.