I think this could be corrected by calling seq on the incoming coll (on the last line of the definition) and that would be in line with the rest of the seq functions in "seq"-ing their arg.
This is kind of a degenerate case of course - sets are always distinct so (distinct <set>) should be the same result as (seq <set>), but it will be slower because it's doing lots of unnecessary work. I suppose it's possible distinct is not supporting sets intentionally for this reason but don't know. On Thursday, March 24, 2016 at 1:21:56 PM UTC-5, puzzler wrote: > > Looking at the source for distinct, the reason it fails is because it > tries to destructure the set as a seq, and sets can't be destructured in > this way. > > A lot of people think that (let [[f & r] coll] ...) is the same as (let [f > (first coll), r (rest coll)]...), but they are not the same, because first > and rest implicitly call seq, but destructuring does not. > > Perhaps this is an oversight in the clojure.core/distinct source. It's > certainly an easy enough change (just change the destructuring line, or > call seq on coll, or do something polymorphic for the case of sets) and > then it would support sets as well. I couldn't speak to that. > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
