.NET Framework正在添加4.0版本的ISet<T>接口。在同一版本中，F＃被添加为一流语言。 F＃提供了一个不可变的Set<'T>类。
对我来说，提供的不可变集合将实现ISet<T>接口似乎是合乎逻辑的，但事实并非如此。有谁知道为什么？
我的猜测是他们不想实现一个可变的接口，但我认为这种解释并不成立。毕竟，他们的Map<'Key, 'Value>类实现了IDictionary，这是可变的。在实现仅部分适当的接口的类框架中的其他地方也有例子。
我的另一个想法是ISet<T>是新的，所以也许他们没有解决它。但这似乎有点薄。
ISet<T>是通用的（v。IDictionary，这不是）与它有什么关系吗？
对此事的任何想法都将不胜感激。
答案 0 :(得分：5)
由于没有其他人加入，我会加上我的推测。首先，大多数IDictionary<'k,'v>接口对于不可变字典仍然有意义;它实际上只是添加或删除不起作用的单个元素。其次，已经编写了大量依赖于IDictionary的代码，因此能够将F＃值与该代码一起使用是个不错的选择。
另一方面，ISet<'t>的几个方法需要变异，不仅包括添加单个元素，还包括几个变异操作符，例如union和intersection。此外，许多设置用例已经被IEnumerable<'t>接口包含在内 - 我认为人们依赖ISet<'t>实现基于不可变集的代码是相对罕见的。
我不认为通用性与它有任何关系 - 请注意，尽管有MSDN文档，但F＃maps实现了通用IDictionary接口，而不是非通用接口。
答案 1 :(得分：5)
Offhand我认为我以前不知道ISet。 （事实上，我回顾过旧的电子邮件，并从2008年发现了一个提到它的BCL计划 - 但就是这样。所以我认为这不在我们的雷达上。）
也就是说，F＃努力在其.NET 2.0和.NET 4.0位之间实现源代码兼容，以便将.NET 4.0实体反向移植到FSharp.Core.dll版本2.0中。例如，2.0 FSharp.Core包含System.Tuple，System.BigInteger，System.Threading.CancelationTokenSource（异步编程模型的一部分）等，ISet可能是另一个工作到后端端口（但我不清楚是否需要移植它）。
我会提出一个问题来看看，虽然现在可能没什么问题。