Pourquoi HashSet<T> ne met pas en œuvre IReadOnlyCollection<T> ?

Question

Je viens de découvrir que .NET Fx dispose désormais de 3 interfaces utiles :

1. IReadOnlyCollection<T>
2. IReadOnlyList<T>
3. IReadOnlyDictionary<K,V>

Et je suis un peu confus pourquoi HashSet<T> ne pas mettre en œuvre IReadOnlyCollection<T> ? Y a-t-il des raisons à cela, ou bien Microsoft a-t-il tout simplement oublié les séries ?

UPD

Après deux heures de recherche sur Internet, j'ai découvert qu'il existe de nombreuses collections dans la BCL qui ont .Count mais ne mettent pas en œuvre la propriété IReadOnlyCollection<T> interface.

UPD2

J'ai trouvé ce post http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/b4fb991a-3f5c-4923-93d4-7cd5c004f859 et la réponse de Immo Landwerth où il a dit ce qui suit

D'autres collections que List<> et Dictionary<> seront-elles mises à jour en fonction de l'évolution de la situation ? pour supporter ces interfaces ?

Absolument. En fait, tous nos types de collections intégrés implémentent déjà implémentent déjà IReadOnlyList<> et IReadOnlyDictionary<>. Cela signifie que vous pouvez passer directement une instance de List, T[] ou Dictionary<> à une API qui API qui en prend une version IReadOnly.

Answer 1

Dans la version 4.5 du cadre, HashSet<T> ne met pas en œuvre IReadOnlyCollection<out T> .

Cette omission a été résolue dans la version 4.6 du cadre (publiée presque 12 mois après que la question ci-dessus ait été posée).

Ces corrections sont sans s'y limiter HashSet<T> d'autres collections telles que Stack<T> y Queue<T> ont reçu ces améliorations.

Les spéculations sur la raison de toute omission sont sans objet. Il peut s'agir d'un oubli ou d'un manque de temps, mais franchement, cela n'a que peu d'importance. Je soupçonne que même une contribution directe de l'équipe de développement de Microsoft serait quelque peu subjective, même si nous apprécions les anecdotes associées.