there are a couple of avenues of things that are worth looking into for merge
: transients && IReduceKV based impls
Scala's new PHMs do merging based on the actual tree nodes themselves. Might be worth a look, too. Michael Steindorfer is the reference for those papers
changing the impl of Map is a non-starter, imho
there's some aborted work in a ticket on transients + map merge, but it needs more analysis
one bounding constraint is that the conj operation (merge {:a :b} [:c :d])
remains valid
why should that a bounding constraint? I've only seen this conj-y way of using merge in beginner's 4clojure solutions. I came across those when validating specs in https://github.com/borkdude/speculative. I've haven't come across this usage anywhere else.
The docstring says merge is intended for maps.
I know docstrings don't always paint the complete picture, but combined evidence ...
compatibility
some maybe it's better to introduce a merge2 then for the hypothetical case anyone was using (merge {} [:a 1])
?
it's not a hypothetical case, I've come across many usages in the wild
whether they were conscious about it, I can't say, but we can't break code
right
;; 8ns
(cc/quick-bench
(reduce-kv assoc {} {}))
thanks for the pointer, will check those out (out of common interest)
The best immediate way to contribute to that ticket is a benchmark suite featuring arguments of different sizes & types to find the baselines.