Does .Net provide a pure IReadOnlyList\<T\> implementation?

[DanTravison]

Alternatively: Why isn't ReadOnlyCollection<T> a pure read-only collection?

I've seen recommendations in various places that ReadOnlyCollection should be used as the implementation class for IReadOnly|T> but this seems like a poor choice since it implements IList and IList<T> with a bunch of stub methods that simply throw NotSupportedException.

From a design standpoint, I feel this is flawed. From a practical standpoint, it can end up producing unintended requirements.

This has bugged me for a while but I recently hit a case where it caused an issue so I figured I'd ask.

A case in point is Maui's CollectionView. While it supports INotifyCollectionChanged, it fails to do so if the ItemsSource does not also implement IList or IList<T>.

The result is I either must use ReadOnlyCollection<T> or implement the list contract with all the appropriate stub methods.

In my case, I implement INotifyCollectionChanged because the collection will change or be reordered and IReadOnlyList because it cannot be publicly updated. As a result, I end up doing both, provide a List<T> to the base class and override List.Contains for custom ordering.

[huoyaoyuan]

this seems like a poor choice since it implements IList and IList with a bunch of stub methods that simply throw NotSupportedException.

This is the de-factor standard since the read-only interfaces came much later in .NET. Both arrays and ImmutableArray<T> implements the non-readonly interface with throwing.

A case in point is Maui's CollectionView. While it supports INotifyCollectionChanged, it fails to do so if the ItemsSource does not also implement IList or IList.

The common practice for xaml collections is to use ObservableCollection. There is ReadOnlyObservableCollection now if you prefer to wrap and avoid casting by users.