--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.
Seems like this would need to be a change in set and vector right?
Seems like this would need to be a change in set and vector right?Sure, okay - can I create an issue for this & submit a patch?
What would be the behavior when passed a specialized data structure? E.g., (set (sorted-set 1 2 3))?
I would thus suggest that this optimisation checks that the data structure passed in is exactly of the type PersistentSet/PersistentVector, and not a subtype of them.
--
I think I'm more in agreement with Kyle that "set" only needs to guarantee that the return is an IPersistentSet, not that it's a PersistentHashSet.
I'd like to see some benchmarks. I have outsmarted myself in the past by optimizing special cases only to find out that the benefit was negligible and the cost was higher than expected for general usage.
It would also be interesting to know how often (set already-a-set) was called in some existing projects. In my code, it would be rare, but that's just me.
Just a suggestion about the proposed patches in CLJ-1410: I would not change the doc strings. I would like to leave some room for the implementation to do what it thinks is best without demanding that the result is identical to an existing set.
Hey Alex,I think I'm more in agreement with Kyle that "set" only needs to guarantee that the return is an IPersistentSet, not that it's a PersistentHashSet.Given that this is a core fn, my thinking was just to suggest the most conservative possible move. I can imagine that some folks may be incorrectly depending on `set` to return a PersistentHashSet specifically.
--