distinct 应当支持集合

Question

我惊讶地发现，当在集合上调用 distinct 时会抛出异常，例如：
(distinct #{1 2 3})

一种解决方案是首先在集合上调用 seq：(distinct (seq #{1 2 3}))

然而，当其他所有我能想到的序列操作符（如 map、keep、reduce、first、some 等）都能接受集合时，这看起来是一种不必要的仪式。

此外，distinct 的文档字符串表明：
> 返回一个不包含重复元素的元素的懒序列。

由于 (coll? #{1 2 3}) => true，这对用户来说很令人困惑。

与此相关的一些讨论在 math.combinatorics 中有所呈现 这里 和 这里，但没有真正的决定。

我建议 distinct 应该接受任何可序列化集合。

Answer 1

集合已经互斥了 - 为什么要在上面调用 distinct 呢？

Comments

如果你有一个函数，接受一组元素，但你不能确定它是一个集合还是一个向量，对吧？除非你测试了函数体内部。

---

我将“我建议distinct应内部支持集合”改为“distinct应接受任何可序列化的集合”。

---

Stan说得对，我的封装函数接受所有集合，并且我需要得到不同的值同时保留顺序。我已经根据你提出的说法Alex更新了我的问题，感谢你们两个。

---

我想distinct不仅仅是在序列函数中，并没有取到一个集合。distinct的step函数使用了结构化来查看集合中的第一个元素；结构化使用了nth；而nth不适用于集合。（nth的文档字符串也把参数称为"coll"，但列举了允许的具体类型。）

与其深入探讨仅修复distinct的利弊，不如更深入地解决nth本身的问题，从而解决这个问题，并且这个解决方案将广泛应用。现在，nth测试了多个情况，最后一个是对顺序性事物的O(n)时间。为什么不添加另一个案例来覆盖可序列化的事物呢？与contains?不同，nth没有 quarters关于蛮力。而且，因为nth是结构化的工具，它不会非常蛮力（大多数情况下只需访问最前面的少量成员）而且好处将广泛。

---

这不是一个好的主意。nth 用于索引或有序集合，而集合不是。更好的解决方案是 distinct 将其输入转换为序列，产生集合的稳定逻辑列表视图，类似于所有其他序列函数。

Answer 2

记录在 https://clojure.atlassian.net/browse/CLJ-2747

Comments

由于 transducer 版本运行良好且行为不同，这应该已得到修复。

```
(into [] (distinct) #{:a :b})
=> [:b :a]
```

常规 distinct 实现选择使用结构化，这需要 nth。

是的，我们也有一些实用函数，它们接受 `coll` 并期望在所有类型的 coll 上运行。