Why doesn't the F# Set implement ISet<T>?

Question

The .NET Framework is adding an ISet<T> interface with the 4.0 release. In the same release, F# is being added as a first-class language. F# provides an immutable Set<'T> class.

It would seem logical to me that the immutable set provided would implement the ISet<T> interface, but it doesn't. Does anyone know why?

My guess is that they didn't want to implement an interface intended to be mutable, but I don't think this explanation holds up. After all, their Map<'Key, 'Value> class implements IDictionary, which is mutable. And there are examples elsewhere in the framework of classes implementing interfaces that are only partially appropriate.

My other thought is that ISet<T> is new, so maybe they didn't get around to it. But that seems kind of thin.

Does the fact that ISet<T> is generic (v. IDictionary, which is not) have anything to do with it?

Any thoughts on the matter would be appreciated.

Answer 1

Offhand I don't think I was previously aware of ISet. (Actually I looked back through old email, and found one mention of BCL plans for it--from 2008--but that was it. So I think it wasn't on our radar.)

That said, F# strives to be source-compatible between its .NET 2.0 and .NET 4.0 bits, to the point of back-porting .NET 4.0 entities into FSharp.Core.dll version 2.0. For example, The 2.0 FSharp.Core contains System.Tuple, System.BigInteger, System.Threading.CancelationTokenSource (part of the async programming model), etc., and ISet would potentially be another bit of work to back-port (it's unclear to me if it would be 'necessary' to port it, though).

I'll file an issue to have a look, though it may be moot at this point in time.

Answer 2

Since no one else is jumping in, I'll add my speculation. First of all, the majority of the IDictionary<'k,'v> interface still makes sense for an immutable dictionary; it's really only adding or removing individual elements that won't work. Secondly, there's a decent amount of code that has already been written which relies on IDictionary, so being able to use F# values with that code is a nice plus.

On the other hand, several of ISet<'t>'s methods require mutation, including not just adding individual elements, but also several set mutating operators such as union and intersection. Additionally, many set use cases are already subsumed by the IEnumerable<'t> interface - I think that it will be relatively rare for people to rely on ISet<'t> implementations for immutable set based code.

I don't think that genericity has anything to do with it - note that despite the MSDN documentation, F# maps implement the generic IDictionary interface, not the non-generic one.