为什么F#Set不能实现ISet <T>？

Question

.NET Framework正在添加ISet<T>4.0版本的接口.在同一版本中,F#被添加为一流语言.F#提供了一个不可变的Set<'T>类.

对我来说,提供的不可变集合将实现ISet<T>接口似乎是合乎逻辑的,但事实并非如此.有谁知道为什么？

我的猜测是他们不想实现一个可变的接口,但我认为这种解释并不成立.毕竟,他们的Map<'Key, 'Value>类实现IDictionary,这是可变的.并且在实现仅部分适当的接口的类的框架中的其他地方存在示例.

我的另一个想法是ISet<T>新的,所以也许他们没有解决它.但这似乎有点薄.

ISet<T>通用(v.IDictionary,不是)的事实是否与它有关？

对此事的任何想法将不胜感激.

Answer 1

由于没有人跳进去,我会加上我的推测.首先,大多数IDictionary<'k,'v>接口对于不可变字典仍然有意义; 它实际上只是添加或删除不起作用的单个元素.其次,已经编写了大量依赖的代码IDictionary,因此能够在代码中使用F#值是个不错的选择.

另一方面,几种ISet<'t>方法需要变异,不仅包括添加单个元素,还包括几个变异操作符,例如union和intersection.此外,许多设置用例已经被IEnumerable<'t>接口包含在内- 我认为人们依赖基于ISet<'t>不可变集合的代码的实现是相对罕见的.

我不认为通用性与它有任何关系 - 请注意,尽管有MSDN文档,但F#maps实现了通用IDictionary接口,而不是非通用接口.

Answer 2

我不认为我以前没有意识到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将可能是工作到后台端口(这是我不清楚它是否会是"必要的"端口的另一位它,但是).

我会提出一个问题来看看,虽然这个时间点可能没什么问题.