System.Collections.Specialized collections should implement generic collection interfaces

[justinvp]

Along the lines of #13933, some of the specialized collections should implement the generic collection interfaces...

I'll update this description with a more detailed proposal speclet, and would be happy to contribute a PR.

[sharwell]

This request took at least an hour longer than I expected before it showed up 😉

[justinvp]

I'm going to close this based on @davkean's comments in dotnet/corefx#370:

However, these collections, along with System.Collections.NonGeneric are entirely there for backwards compatibility - we don't want to invest in them, we don't want to add features to them. There are better and more appropriate replacements for them. Adding features, including generic interfaces, makes them more attractive to use, which is entirely not want we want and on top of that, hiding these public properties/methods, can only break code that was using them (whether correctly, or incorrectly) that ports to .NET Core.

This also applies to implementing generic interfaces, we know for a fact that this will break serialization on .NET Framework - we recently rolled back our implementation of IDictionary<TKey, TValue> on StringDictionary due to this.

To summarize, I believe that these should be ported as is, warts and all, to .NET Core with very little changes, solely for source compatibility. Let's spend the investment elsewhere, on the libraries and types that we want to invest and bring forward.

Note that implementing the generic interfaces on some of these specialized collections is trivial (see justinvp/corefx@77ab2c1 for StringCollection), but it's less trivial on others. If these are only meant to be used for backwards compatibility purposes, then there's no point in further investment, especially if it would make them more attractive to use when other more appropriate types are preferable.