Okay, so I'm taking a look at http://dev.clojure.org/jira/browse/CLJS-1453

And it looks like the most obvious way to fix it is to change https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L3305

But I have no idea what the ramifications of that change are.

@angusiguess I'm guessing since the order is random anyway, changing it to a vector wouldn't change much

for :requires

I'd just call distinct at the end to ensure no duplicates

Hi, When creating an iterator from a cljs.core.SubVec, the type of the wrapped vector is not checked. This is dangerous because RangedIterator makes assumptions on the PersistentVector internals. This also differs from the Clojure implementation: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L5470 vs https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentVector.java#L565 As a consequence, cljs.core.subvec is incompatible with alternative Vector implementations Can I open a ticket for this ?

actually, the difference is that clojurescript's ranged iterator uses persistent vectors internals directly while clojure's ranged iterator only uses "nth" from Indexed

when passed a nil coll, clojurescript's assoc returns an hash-map, shouldn't be an array-map instead ?

cljs.core.MetaFn alone adds 8K of javascript code to cljs.core. It's probably rarely needed by clojurescript users. It cannot be removed by the closure compiler because cljs.core uses "with-meta" at multiple places. Almost everywhere cljs.core uses "with-meta" it could use "-with-meta" instead. By doing this, MetaFn gets removed for users who do not explicitly use "with-meta" or "vary-meta". Would a patch be considered ?