Clojure Q&A - Recent questions

Reflection warning when long hint on an argument

Fri, 01 May 2026 19:49:31 +0000

Hi,

I noticed some reflection warning that goes away when removing a hint from fn arguments. I would like to understand the reason for this.

Example, loading this code

(set! *warn-on-reflection* true)

(defn duration-of-seconds
  (^java.time.Duration [^long seconds]
   (java.time.Duration/ofSeconds seconds)))

(defn sleep
  [seconds]
  (Thread/sleep (duration-of-seconds seconds)))

Raises a reflection warning:

call to static method sleep on java.lang.Thread can't be resolved (argument types: java.lang.Object).

However, just removing the ^long hint from the duration-of-seconds fn argument, makes the reflection warning go away.

Thanks!

Default implementation of AsElements to treat numbers as numbers, not strings

Tue, 28 Apr 2026 16:10:26 +0000

I'm slowly converting some code from using xml/element to xml/sexp-as-element, and I've noticed a discrepancy. xml/element does (almost) no processing of the "content", inserting it directly (unless it's nil). xml/sexp-as-element calls (str) on the "content" if it's not seq of some kind (vector or ISeq) or a keyword. This means that (= (xml/element :foo {} 1) (xml/sexp-as-element [:foo 1])) is false.

There are probably other differences, but this one seems relatively big, as there's no way to use numbers in xml/sexp-as-element without calling extend-protocol yourself.

May I recommend/request adding this extension? It will make xml/sexp-as-element match xml/element for numbers, and make xml/sexp-as-element match hiccup in general.

(extend-protocol clojure.data.xml.protocols/AsElements
  java.lang.Number
  (as-elements [n] [n]))

Installing Clojure on IPv6-only machine

Fri, 24 Apr 2026 23:21:53 +0000

Since GitHub (still) do not support IPv6 it is not possible to follow the instructions at https://clojure.org/guides/install_clojure (for Linux, say) to install the Clojure CLI on a machine running ONLY IPv6 (in this case Hertzner).

When downloading the .tar.gz-file manally and uploading it directly, installing the CLI tools is possilbe.

The problems seem to continue installing common clojure dependencies, like data.json 2.5.2, which leads to this:

clj -X:server
Error building classpath. Failed to read artifact descriptor for org.clojure:data.json:jar:2.5.2
org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.clojure:data.json:jar:2.5.2
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:255)
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:171)
	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:263)
	at clojure.tools.deps.extensions.maven$read_descriptor.invokeStatic(maven.clj:115)
	at clojure.tools.deps.extensions.maven$fn__1340.invokeStatic(maven.clj:143)
	at clojure.tools.deps.extensions.maven$fn__1340.invoke(maven.clj:143)
	at clojure.lang.MultiFn.invoke(MultiFn.java:244)
	at clojure.tools.deps$expand_deps$children_task__959$fn__961$fn__962.invoke(deps.clj:299)
    ...
Caused by: java.net.SocketException: Network is unreachable
at java.base/sun.nio.ch.Net.connect0(Native Method)
at java.base/sun.nio.ch.Net.connect(Net.java:546)
at java.base/sun.nio.ch.Net.connect(Net.java:535)
at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:585)
at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.jar

All this seem a bit bisarre of course. Workarounds would make me happy!

"Nested" vs "lateral" exception causes

Sun, 05 Apr 2026 14:18:26 +0000

Currently, clojure.core/ex-info must take a msg and data map, and may take a cause, which must be another Throwable, which may have its own cause, etc. etc..

This supports the case of "nested" exceptions quite well, e.g. in the case of compilation exceptions being caused by macroexpansion exceptions, potentially with their own cause, and works well for fail-on-first-problem situations.

There's also the situation of "lateral" exceptions, e.g. in the case of test runners or static analysers, which is not supported. In this case, if we take lazytest as a concrete example, the test runner throws an exception if any of the test cases it runs throws an exception, but the overall cause of the overall exception, conceptually, is all the individual exceptions.

Currently, the only to do this is to make some bespoke thing in the data map.

I propose changing clojure.core/ex-info to take [msg map & causes], which would be a non-breaking change (or, while we're at it, make the map arg optional as well and default it to {}, but that's a separate topic).

That leaves the question of how to handle ex-cause. To my understanding, to change it to return the cause or the list of causes, would maybe be a breaking change for general exception handling libraries or something, but would not imo pose any significant problem. Alternatively, we might have ex-causes to always return a list, and change ex-cause to (comp first ex-causes).

Any thoughts? I don't trust myself to spearhead a PR alone on this but I'd love to contribute, certainly the pure-clojure side of things seems straightforward enough (and I'd love to patch this into lazytest, but that's again a different topic).

Destructuring {:as opts} unexpected behaviour with seq

Sat, 04 Apr 2026 23:50:39 +0000

Hi,

I found out something weird in some old code, where I wanted to pass the first map in a sequence and by mistake the code was working while actually passing the sequence itself!

After digging to make sense of this, I found out it has to do with the {:as opts} destructuring.

Here's some code:

;; even if something is assigned sequential vs associative
;; the `:as` is transparent
(let [[:as opts] {1 2 3 4}]
  opts)
#_=> {1 2, 3 4}
(let [{:as opts} [1 2 3 4]]
  opts)
#_=> [1 2 3 4]
;; however with a seq it's returned as a map
(let [{:as opts} (seq [1 2 3 4])]
  opts)
#_=> {1 2, 3 4}

;; and it only gets weirder!
(let [{:as opts} (seq [{:k :v}])]
  opts)
#_=> {:k :v}
(let [{:as opts} (seq [{:k1 :v1} {:k2 :v2}])]
  opts)
#_=> {{:k1 :v1} {:k2 :v2}}
(let [{:as opts} (seq [{:k1 :v1} {:k2 :v2} {:k3 :v3}])]
  opts)
#_=> {{:k1 :v1} {:k2 :v2}, :k3 :v3}
(let [{:as opts} (seq [{:k1 :v1} {:k2 :v2} :not-a-map])]
  opts)
;; java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Keyword
(let [{:as opts} (seq [1 2 3])]
  opts)
;; java.lang.IllegalArgumentException: Don't know how to create ISeq from: java.lang.Long

In my case I didn't realize my code was wrong because {:as opts} {:k :v} is the same as {:as opts} (seq [{:k :v}]).

To me this is behaviour I would expect closer to & {:as opts} rather than just plain map destructuring {:as opts}. Maybe both behaviours should be separated?

I think this should be tackled either by
1. make :as transparent regardless of what comes in to always bind
2. throw an error earlier when it's not of the expected destructuring
3. Document this very unexpected edge case in https://clojure.org/reference/special_forms#associative-destructuring
4. Separate the keyword arguments use case from plain map destructuring? (Assuming both are now mixed together)

Optimize `eduction`

Fri, 03 Apr 2026 14:25:17 +0000

Problem statement

Eduction is useful part of the transducer ecosystem, which has a benefit/aim of improved performance. However, the function eduction only has a single varargs arity, which adds multiple function calls and and seq traversal allocations.

As seen in this PR to clj-kondo, manually passing in an xform directly can improve both overall performance and lower allocations.

Proposal

Adding arities to eduction can sidestep those allocations and seq traversals, improving baseline performance of all eduction invocations.

(defn eduction2
  {:arglists '([xform* coll])
   :added "1.7"}
  ([coll] (->Eduction identity coll))
  ([f1 coll] (->Eduction f1 coll))
  ([f1 f2 coll] (->Eduction (comp f1 f2) coll))
  ([f1 f2 f3 coll] (->Eduction (comp f1 f2 f3) coll))
  ([f1 f2 f3 f4 & args]
   (->Eduction (apply comp f1 f2 f3 f4 (butlast args)) (last args))))

Missing protocol error will hang on infinite `(range)` input in ClojureScript but not Clojure

Fri, 03 Apr 2026 11:16:47 +0000

functions like transient, assoc, etc will throw helpful missing-protocol error when receiving invalid input but it will hang if it receives infinite (range).
this is related to issue below
https://ask.clojure.org/index.php/14578/even-range-hangs?show=14578#q14578

however, missing-protocol only hang in clojurescript but not clojure so I am wondering if this difference is intended.

example calls that should throws
- (transient (range))
- (assoc (range) :a 1)

requiring an empty .clj without an alias should fail as with an alias

Thu, 02 Apr 2026 18:48:37 +0000

if file a/b/c.clj is "empty"

it creates an empty ns: (and does not fail) when doing

(require '[a.b.c])

while when using ":as" it fails correctly with error:

(require '[a.b.c] :as c)

Syntax error compiling at ... ; namespace 'a.b.c' not
found after loading '/a/b/c'

see here for initial discussion:
https://clojurians.slack.com/archives/C03S1KBA2/p1775155101843229?thread_ts=1775153939.803389&cid=C03S1KBA2

Does Clojure have an anti LLM code contributions policy? Would it make sense for Clojure to adopt one?

Sun, 29 Mar 2026 13:14:25 +0000

LLM use appears to have a bunch of ethical and practical problems, the most pressing one seems to be the plagiarism that seems to be pretty excessive even for code and even when not baited:

Video clip of apparently a lawyer live demoing what seems to be Co-Pilot plagiasm

I don't know anything about law, but the lawyer at one point says: "This is a copyright infringement." I've also found this: https://www.twobirds.com/en/insights/2025/landmark-ruling-of-the-munich-regional-court-(gema-v-openai)-on-copyright-and-ai-training It seems to talk about "fair use" of AI model training.

Also see this high-profile incident: https://www.pcgamer.com/software/ai/microsoft-uses-plagiarized-ai-slop-flowchart-to-explain-how-github-works-removes-it-after-original-creator-calls-it-out-careless-blatantly-amateuristic-and-lacking-any-ambition-to-put-it-gently/

Also this field study that appears to be putting the plagiarism rate at seemingly at least 2-5%: https://dl.acm.org/doi/10.1145/3543507.3583199

This article mentions a study that apparently puts the plagiarism rate at 8–15% as a minimum for the easily detectable kind: https://www.theatlantic.com/technology/2026/01/ai-memorization-research/685552/

I don't know what this means legally, but at least morally and ethically this seems sad.

Apparently, some people in the Clojure space already spoke out against LLMs, but I wasn't able to find any anti LLM policy. If there was such a policy, I would expect it to be mentioned in the following places:

I simply wanted to suggest that perhaps the project may want to adopt such a policy.

Here are some other projects that have already done so: Asahi Linux, elementaryOS, Forgejo, Gedit, Gentoo, GIMP, GoToSocial, Löve2D, Loupe, NetBSD, postmarketOS, Qemu, RedoxOS, Servo, stb libraries, Zig.

My deepest apologies if there already is such a policy, or if I'm asking in the wrong space.

Is taggedliteral's equality check inefficient?

Fri, 27 Mar 2026 13:43:44 +0000

Following on from a very interesting article about tagged literals: https://buttondown.com/tensegritics-curiosities/archive/when-you-run-out-of-types/ I noticed that the implementing class checks for value equality before checking for tag equality.

if (form != null ? !form.equals(that.form) : that.form != null) return false;
if (tag != null ? !tag.equals(that.tag) : that.tag != null) return false;

This leads to the following type of comparison that could be answered immediately but instead takes over a second:

impl=> (time (= (tagged-literal 'foo (seq (range 1e7))) (tagged-literal 'bar (butlast (seq (range 1e7))))))
"Elapsed time: 1911.677375 msecs"
false

it checks if these huge seqs are equal and then compares the associated symbols. Swapping this seems identical semantically but with less computation.

Why doesn't defn also implicitly name the anonymous function it defines for recursion?

Sat, 21 Mar 2026 13:49:43 +0000

Why doesn't defn implicitly name the function to create a named recursion point?

(clojure.walk/macroexpand-all
  '(defn foo [x]
     (foo x)))
; =>
(def foo
  (fn*
    ([x]
     (foo x))))

This could instead expand to

(def foo
  (fn* foo ; note the foo here
    ([x]
     (foo x))))

How it works right now, foo resolves to a global var #'foo, which is created when the (def ...) form is analyzed. In the second case, it resolves directly to the function object. Thus, it should save us a var dereference at runtime in this case.

EDIT: Found out, this is exactly what direct linking is used for.

Controlled Bailout, Jira issue 2213

Sat, 21 Mar 2026 10:14:48 +0000

I would like to improve Issue 2213 as follows. Do you think, this makes sense? Shall I become contributor for this?

The new description would be:

When developing Input-Process-Output tools I am often in the situation, that I have a sequence of activities (e.g. opening a file, spec checking a file, calling external tools, creating files), which each could fail in certain ways. Clojure does not have a good way to control such a sequence of activities in a way that all sorts of things, which could go wrong, can be handled comfortably. In imperative programming languages concepts like early exit or bailout are used. These are not not very functional. Unfortunately practical problems are often like this.

The issue is a bit more general and a solution would be nice not only for those who develop such sort of tools. So I can give a simple example.

(let [config-file (get-file-from-network xy)
      config-file (parse-edn config-file)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

As all these steps can fail, we could instead implement it like this.

(if-let [config-file (get-file-from-network xy)]
  (if-let [config-file (parse-edn config-file)]
    (if (spec-check config-file)
      (do-something-with config-file))))

Now the code has suffered already a lot. The sequential nature of the problem is lost. And it is not even doing what we need. We have to report to the user what went wrong.

(if-let [config-file (get-file-from-network xy)]
  (if-let [config-file (parse-edn config-file)]
    (if (spec-check config-file)
      (do-something-with config-file)
      :file-has-syntax-errors)
    :file-not-valid-edn)
  :file-cannot be openned)

But this is still not doing what we need. We have to provide more information about each failure. If a file cannot be openned, is it because the file does not exist or we do not have read permissions? And what did the spec check tell us? So we cannot just use nil as a universal failure. We must deliver more information when failing. And we cannot use if-let, either. So we are not even done.

This problem report asks for a better solution for this conceptual challenge.

This example depicts a conflict that should not happen when using an appropriate programming language: First we are able to quickly make a prototype. But in the end the final code has not much in common with the first code any more. The final design is not driven by the problem domain, but by the technical need for an error handling. The need for a bailout mechanism in this example imposes too many huge code changes.

The principal problem with all these solutions is that they coerce a sequence of actions into something which is not a sequence. If your problem is a sequence, then the implementation should also be a sequence.

Idea: Exceptions

As an alternative implementation I went with Exceptions. But it feels wrong, because I am talking about things, that are expected to fail. I cannot just use the Exceptions that are comming out of Java for example when opening a file for read. I need detailed information, what went wrong. If you are a command line tool, it is expected from you, that you provide good error messages. I ended up catching and rethrowing exceptions everywhere in the program.

Idea: Like for/doseq

For me I created a small macro, that extends let. Then I use this syntax:

(let [[config-file error] (get-file-from-network xy)
      :escape     error
      config-file (parse-edn config-file)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

This often allows a surprisingly intuitive code. For example here:

(let [[config-file error-code] (get-file-from-network xy)
      :escape     (if (= error-code :does-not-exist) 
                    :file-xy-does-not-exist)
      :escape     (if (= error-code :io-error)
                    :file-xy-cannot-be-read)
      [config-file error-code] (parse-edn config-file)
      :escape     (if error-code :file-xy-not-legal-edn)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

This is inspired by the for/doseq. But I don't claim that this is a good solution for Clojure (although I think so). But I think, the let macro is a good candidate when improving how Clojure can be used for such imperative things.

Idea: Using `if-let`

I also investigated the solution, that was originally proposed by this issue.

(if-let [config-file (get-file-from-network xy)
         config-file (parse-edn config-file)
         config-file-ok? (spec-check config-file)]
  (do-something-with config-file)
  :error)

This problem with this solution is that none of the bindings are available in the else part. That makes it very hard to react accordingly. This is a nice and small new language feature. But I don't think, that in practice it would be of help so often. The example from the original issue was very artificial with mathematical operations that cannot fail. The first draft of this issue with that artificial example does not actally describe a real problem. That is why this issue has completelly been rewritten.

Or course we could still bind everything, which was not failed. But I don't think, we would want that. It would have very interesting consequences to the compiling model.

Idea: Threading macros

As this issue is a about a sequence of activities, a new type of threading macro (e.g. let->) could also be an intuitive solution. But I have not tried anything like this.

Final Words

The principle challenge is, that all these solutions establish a sort of alternative control flow. It is a hard challenge to do this right, especially in a functional language. Like exceptions, that immediatelly exit and magically jump somewhere else. Clojure as a practically language could address this challenge.

Is the recent change to flow's futurize safe?

Tue, 17 Mar 2026 15:54:00 +0000

Previously flow's futurize would rethrow any exceptions thrown by the function when deref'ed. With the recent changes to return a CompletableFuture it no longer does that and instead if the function throws deref'ing will just hang forever.

Evaluating forms using eval can create a valid undesirable recursion point

Mon, 16 Mar 2026 23:17:54 +0000

When the eval function in Clojure is called with an argument that is an instance of IPersistentCollection which likely isn't a special def-like form (the first element isn't a symbol at all or it does not start with "def"), the form is first wrapped in an anonymous function which then gets compiled and invoked, which indirectly evaluates the original form.

There aren't any extra checks performed and it makes forms like these 2 valid, which should normally be rejected and a compiler exception should be thrown:

(recur)

(let []
  (print "Hello")
  (Thread/sleep 1000)
  (recur))

where the 2nd form keeps printing "Hello" and loops infinitely over the outer wrapper function.

Optimized str function

Mon, 16 Mar 2026 11:12:53 +0000

Opimized version of str function:

(defn my-str
  (^String [] "")
  (^String [^Object x]
   (if (nil? x) "" (. x (toString))))
  (^String [^Object x & ys]
   (let [sb (StringBuilder. (if (nil? x) "" (. x (toString))))]
     (loop [ys (seq ys)]
       (if-not (nil? ys)
         (let [x (.first ys)]
           (if-not (nil? x)
             (.append sb (.toString ^Object x)))
           (recur (.next ys)))))
     (.toString sb))))

Benchmarks:

(let [xs (vec (range 1000))]
    (criterium/bench
      (apply my-str xs)))

Evaluation count : 2577840 in 60 samples of 42964 calls.

         Execution time mean : 23.611394 µs

(let [xs (vec (range 1000))]
    (criterium/bench
      (apply str xs)))

Evaluation count : 1375200 in 60 samples of 22920 calls.

         Execution time mean : 42.015320 µs

shasum not found error when using ./posix-install on linux

Wed, 11 Mar 2026 21:49:11 +0000

I was redeploying an AWS beanstalk application. I was installing clojure using the commands from the clojure install guide for posix

commands:
  01_install_clojure:
    command: |
      curl -L -O https://github.com/clojure/brew-install/releases/latest/download/posix-install.sh
      chmod +x posix-install.sh
      sudo ./posix-install.sh

I believe this used to work, but it now fails with

./posix-install.sh: line 30: shasum: command not found

Using the linux instructions worked just fine. I can provide more info about the linux envorionment, but it was using aws' "Corretto 17 running on 64bit Amazon Linux 2023/4.10.0" platform which is one of the builtin java platforms for beanstalk.

tools.cli: capture unrecognized options as unparsed arguments

Fri, 06 Mar 2026 00:35:16 +0000

I frequently write a command that accepts options and in turn execute a shell command passing arguments through; I want to be able to specify additional arguments to that shell command.

In tools.cli, the :in-order key almost does what i want:

`
(require '[clojure.tools.cli :as cli])
=> nil
(def opts [["-d" "--debug"]])
=> #'net.lewisship.cli-tools-test/opts
(cli/parse-opts

["--foo"]
[]
:in-order true)

=> {:options {}, :arguments [], :summary "", :errors ["Unknown option: \"--foo\""]}
(cli/parse-opts

["xxx" "--foo"]
[]
:in-order true)

=> {:options {}, :arguments ["xxx" "--foo"], :summary "", :errors nil}
`

However, it will assume an undefined option is an error until the first non-option argument is consumed.

I would like a further option that is like :in-order but accepting of these unrecognized options. Maybe, :passthru-options would be a good name?

I can work on a patch if we have some consensus on direction.

It's difficult to figure out options I can pass to slurp function.

Fri, 27 Feb 2026 06:41:39 +0000

(doc slurp) says

clojure.core/slurp
([f & opts])
Opens a reader on f and reads all its contents, returning a string.
See clojure.java.io/reader for a complete list of supported arguments.

(doc clojure.java.io/reader) says

clojure.java.io/reader
([x & opts])
Attempts to coerce its argument into an open java.io.Reader.
Default implementations always return a java.io.BufferedReader.

Default implementations are provided for Reader, BufferedReader,
InputStream, File, URI, URL, Socket, byte arrays, character arrays,
and String.

If argument is a String, it tries to resolve it first as a URI, then
as a local file name. URIs with a 'file' protocol are converted to
local file names.

Should be used inside with-open to ensure the Reader is properly
closed.

I read the source code, and I was confused even more.

clojure.core.cache caches delays that hold exceptions as of version 1.2.254

Mon, 23 Feb 2026 19:43:34 +0000

As of version 1.2.254 of org.clojure/core.cache, using a value-fn that throws will cause an entry to be added to the cache associated with a Delay with :status :failed and the exception as a value.

The code below can be used to compare the behavior between versions 1.1.234 and 1.2.254.

(require '[clojure.core.cache.wrapped :as cw])

(def counter (atom 0))

(defn value-fn [v]
  (prn :value-fn-called)
  (swap! counter inc)
  (if (= @counter 1)
    (throw (ex-info "thrown" {}))
    v))

(def test-cache (cw/lu-cache-factory {} :threshold 10))

(reset! counter 0)
; this will throw
(cw/lookup-or-miss test-cache "throw" value-fn)
; in 1.1.234 this will call value-fn again and not throw; in 1.2.254, it won't call and return
; the cached delay result, which is an exception
(cw/lookup-or-miss test-cache "throw" value-fn)

; evict to force call to value-fn
(cw/evict test-cache "throw")

This is related to work done in CCACHE-65 to avoid cache stampede in multi-threaded applications, and could be related to what has been reported in CMEMOIZE-31.

This was initially reported in Clojurians Slack.

Is it legal for a namespace to start with a number?

Mon, 23 Feb 2026 18:53:53 +0000

There are rules (informally in the spec, formally in the reader) about disallowing symbols to start with numbers: (def 1asdf 5) However, there aren't rules about namespaces (either middle segments or as the final segment) starting with numbers, leading to their usage in the wild. (For example: https://github.com/marick/Midje/tree/bee206983db22c6dc92044fd7b5b0365bbd44fc6/test/implementation/parsing/0_to_fact_form)

Is this intentional? Should such namespaces be considered legal or not?

Feature Request:Make anonymous fn/reify class name IDs per namespace instead of one global counter

Wed, 18 Feb 2026 15:34:38 +0000

Compiled anonymous functions and reify classes get names like ns$fn__4532, where the numeric suffix comes from a global AtomicInteger counter
(RT.nextID()).

This counter is shared across the entire runtime and is consumed by fn classes, reify classes, constants tables, gensyms, etc.

The problem is that because the counter is global, any code change shifts the IDs for everything compiled after it. This makes profiling across builds
really painful, you can't meaningfully compare flame graphs because all the class names change even in code you didn't touch.

I'd like to propose scoping the ID counter per-namespace instead. Since the namespace is already part of the class name prefix, uniqueness is still
guaranteed. This would eliminate the cascading effect across unchanged namespaces and make profiling diffs actually useful.

I'm not sure what's the downsides of this, but from what I saw of AtomicInteger, it isn't used a lot to break things.

Thank you!

Is it valid for metadata to have metadata?

Thu, 12 Feb 2026 15:45:20 +0000

Hello,

I am implementing a pretty printer and while adding/testing support for *print-meta* I noticed that pr prints an object whose metadata has metadata in the following way:

user> (binding [*print-meta* true]
        (pr-str (with-meta 'foo (with-meta {:bar :baz} {:frob :zork}))))
"^^{:frob :zork} {:bar :baz} foo"

When reading such a form, only the "outermost" metadata is preserved:

user> (binding [*print-meta* true]
        (let [s (pr-str (with-meta 'foo (with-meta {:bar :baz} {:frob :zork})))
              o (clojure.edn/read-string s)]
          {:o o
           :meta (meta o)
           :metameta (meta (meta o))}))
{:o foo, :meta {:bar :baz}, :metameta nil}

The behaviour is the same for clojure.core/read-string and also the tools.reader readers.

Can anyone clarify for me if this is either:

simply GIGO
a bug in the printer
a bug in the readers
a state that should be somehow disallowed
something else?

Neither the metadata reference nor the reader reference explicitly allow or disallow such a thing, as far as I can tell. Should they?

N.B. this is not an issue in any kind of production context and I'm not aware of any library or program that constructs such a thing. It's simply something I tested to see if/how it would break the pretty printer I'm building.

EDIT:

I dug into this some more with Nicola. Here's a perhaps much clearer case that demonstrates the reader isn't propagating nested metadata:

user> (let [o ^^:foo {1 2} {3 4}]
        {:o o :meta (meta o) :metameta (meta (meta o))})
{:o {3 4}, :meta {1 2}, :metameta nil}

:metameta should be {:foo true}.

In this section of MetaReader.invoke we are iterating over the entries of the meta map and manually associng them into the existing meta of the object; any metadata on the meta map itself is not preserved. I have a patch that adds a failing test case and correctly propagates the the meta map's metadata. If this is worth a ticket then I'm more than happy to attach it to that or send it to you directly.

does deps.edd support "exclusion" with wild cards ?

Sat, 07 Feb 2026 21:12:28 +0000

maven supports this:

<dependency>
      <groupId>org.apache.hadoop</groupId>
      <artifactId>hadoop-common</artifactId>
      <version>${hadoop.version}</version>
      <exclusions>
        <exclusion>
          <groupId>*</groupId>
          <artifactId>*</artifactId>
        </exclusion>
      </exclusions>

while Clojure does not , it seems

javadoc-data-fn does not find selected method for inherited methods

Sat, 07 Feb 2026 19:55:52 +0000

Even though java.util.jar.JarEntry/.getName is a valid qualified method, the selected method docs aren't found.

> java.util.jar.JarEntry/.getName
 #function[...]

> (clojure.java.doc.api/javadoc-data-fn
   "java.util.jar.JarEntry/.getName"
   nil)
{:classname "java.util.jar.JarEntry",
 :class-description-html "<section ...",
 :class-description-md "All Implemented...",
 :methods
 [{:signature "getAttributes()",
   :description
   "Returns the Manifest Attributes for this entry, or null if none.",
   :static? false,
   :return-type "Attributes",
   :clojure-call "java.util.jar.JarEntry/.getAttributes"}
  ...],
 :selected-method []}

clojure.java.doc.api/javadoc-data-fn does not include constructor info

Fri, 06 Feb 2026 05:58:34 +0000

It would be helpful to include the constructor summary info from the javadoc. I tried querying the class as well as the /new method value.

(clojure.java.doc.api/javadoc-data-fn 
 "java.io.PushbackReader/new" nil)
(clojure.java.doc.api/javadoc-data-fn 
 "java.io.PushbackReader" nil)

I've integrated java.doc into my IDE and it's been very helpful. Thanks!

TypedArrays don't implement ICounted in cljs

Thu, 05 Feb 2026 12:37:54 +0000

I just discovered that JS TypedArrays (Uint8Array et al) do not implement ICounted out of the box, even though it's trivial to make them do so. As a result count doesn't work on them; this is in contrast to Clojure where count works on arrays of primitives. Can/should this be added, or is the current behaviour intended?

(count (js/Uint8Array. [1 2 3]))
;; Execution error (Error) at (<cljs repl>:1).
;; No protocol method ICounted.-count defined for type object: 1,2,3
;=> :repl/exception!

(extend-protocol ICounted
 js/Uint8Array 
 (-count [this] (alength this)))
;=> #object [Function]

(count (js/Uint8Array. [1 2 3]))
;=> 3

bit-count in cljs but not clj

Fri, 30 Jan 2026 09:21:40 +0000

The bit-count function ships as part of CLJS but not CLJ, which means I end up using a reader conditional to use Long/bitCount on the JVM side when I write cljc files. It would be nice if I could just use bit-count.

(I chose "compiler" for category because there's no option for "standard library")

`flow/ping-proc` can be slow or fail to respond, even when process isn't busy

Wed, 28 Jan 2026 18:01:40 +0000

I've run into a few cases where flow/ping and flow/ping-proc are slow and timeout.

I was able to track the issue down to this line https://github.com/clojure/core.async/blob/b871f3519de6843a9f5ce66cf8d5c6cbe44d3222/src/main/clojure/clojure/core/async/flow/impl.clj#L273

(async/>!! c
            (walk/postwalk datafy
                           #::flow{:pid pid, :status status
                                   :state state,
                                   :count count
                                   :ins pins :outs pouts}))

This causes the state of the flow process to be traversed and datafied.

In one case, I had some process state that threw an exception when datafied due to an incomplete datafy extension. This caused flow/ping-proc to silently fail. No errors were reported.

In some other cases, the flow processes were working with large values. Walking the process state was slow and caused pings to respond slowly.

Core Cache and Count

Wed, 28 Jan 2026 16:54:22 +0000

Hi,

I notice that in the wrapped namespace of core.cache, there is a has? function that checks the wrapped cache if it has an element or not. It does this by delegating to the underlying cache c/has? function of the wrapped cache.

For reporting purposes, I need to get the current size of the cache (with the caveat of course that the size could be approximate, given the particular nature of a particular cache - but approximation is fine).

Unfortuantely, a size or count function doesn't exist in the wrapped namespace, it only exists on the wrapped cache itself - thus doing:

(count @wrapped-cache)

does return the value.

It would be good, however, if there was also a similar function in the wrapped namespace, something like this (using size as the function name, but could be something else):

(defn size
   [cache-atom]
   (c/count @cache-atom)

The rationale being that having this function exposed in the wrapped namespace keeps the code consistent - i.e., whilst I can continue to do:

(count @wrapped-cache)

It would more preferrable to keep using the wrapped namespace (as I do with other operations, such as evict), i.e., something along the lines of:

(wrapped/size wrapped-cache)

Do you think this suggestion might be something that could be included in the wrapped namespace?

Thank you.

-=david=-

TDEPS-269: checksums should use sha256sum instead of shasum

Tue, 27 Jan 2026 11:17:20 +0000

This commit broke our Docker build: https://github.com/clojure/brew-install/commit/d6d540756cb0a6342374db529d07f1de35d5bc71

because shasum is a perl executable provided on Fedora by perl-Digest-SHA-1 rpm, but it's not available on the UBI platform. The standard way to validate checksums is through sha256sum provided by coreutils on most (if not all) linux distributions.

The jira ticket even talks about sha256sum, but then the commit doesn't use it: https://clojure.atlassian.net/jira/software/c/projects/TDEPS/issues?jql=project = TDEPS ORDER BY created DESC&selectedIssue=TDEPS-269

definterface doesn't expose gen-interface's :extends for interface extension

Mon, 26 Jan 2026 19:49:08 +0000

gen-interface allow :extends to specify one or more interfaces, which will be extended by this interface.

definterface doesn't expose this.

Use case is working with primitives (where protocols don’t help), to get things to dispatch nicely in a zero boxing primitive transducer implementation.

Improving curl options for CLI install scripts (brew-install)

Mon, 26 Jan 2026 12:39:44 +0000

Hi!

I'm the maintainer for Heroku's Clojure buildpack. It uses the install scripts from clojure/brew-install to install the CLI. I noticed intermittent install failures related to the download of the Clojure tools. I believe most of them could be avoided with a slightly changed curl command line options.

I opened a PR before realizing that PRs will not be accepted, so I'm starting this thread to properly get the discussion going. For reference, the closed PR can be found here: https://github.com/clojure/brew-install/pull/10

I believe these options would improve the download behaviour for all users, but especially when used in automations:

--connect-timeout 3 (https://curl.se/docs/manpage.html#--connect-timeout)
Prevents hanging when server is unreachable.

--fail (https://curl.se/docs/manpage.html#-f)
Exit with error code 22 for HTTP responses with status codes >= 400.

--max-time 60 (https://curl.se/docs/manpage.html#-m)
Maximum time in seconds for the entire transfer operation. Prevents hanging indefinitely with slow connections.

--no-progress-meter (https://curl.se/docs/manpage.html#--no-progress-meter)
Introduced in curl 7.67.0 (Nov 2019). Disables the progress bar for cleaner output. But less drastic than --silent and will still output diagnostic information (i.e. retries).

--retry-max-time 60 (https://curl.se/docs/manpage.html#--retry-max-time)
Retry only within this time period (60 seconds). After this time expires, no more retries will be attempted.

--retry 5 (https://curl.se/docs/manpage.html#--retry)
Introduced in curl 7.12.3 (Dec 2004). Retry up to 5 times on transient errors (timeouts, HTTP 408, 429, 500, 502, 503, 504, 522, 524).

--retry-connrefused (https://curl.se/docs/manpage.html#--retry-connrefused)
Introduced in curl 7.52.0 (Dec 2016). Consider connection refused as a transient error for --retry.

These are obviously opinionated and my ask is not for these options specifically. Happy to get anything that will improve the situation. :)

Manuel

clojure.java.doc.api/javadoc-data-fn does not include return types for methods

Tue, 20 Jan 2026 22:26:31 +0000

Calling clojure.java.doc.api/javadoc-data-fn returns data about methods of a java class in the :methods and :selected-method entries. It does not include any directly accessible description of the return types for methods. The return type for a method can be found indirectly in the :method-description-html and :method-description-md entries of the :selected-methods (but not the :methods entries).

Example:

(def jdoc-data
  (clojure.java.doc.api/javadoc-data-fn "CharSequence/.charAt"
                                        nil))
  
(def my-method (-> jdoc-data :selected-method first))

> my-method
{:signature "charAt(int index)",
 :description "Returns the char value at the specified index.",
 :static? false,
 :clojure-call "^[int] CharSequence/.charAt",
 :method-description-html "<section class ...",
 :method-description-md "### charAt {#charAt(int)}\n\nchar charAt (int index)..."}

How to force clojure.spec generator to skip a field

Thu, 15 Jan 2026 07:58:46 +0000

(gen/let [x (s/gen (s/keys :opt [::a]))
          y (s/gen (s/keys :opt [::a]) {::a ???})])

If x generates without ::a, I'd also like to generate y without ::a. I can't presently see a way to express that.

clojure.core/subs should use type hints of ^CharSequence, NOT ^String

Tue, 13 Jan 2026 18:10:48 +0000

This is related to this ancient ask, but it would be ideal if clojure.core/subs was type hinted with ^CharSequence rather than ^String, and used the subSequence() method instead of substring() (since the latter doesn't exist in CharSequence).

The single parameter version of subs would need to call s.length() as the second argument in the call to subSequence() (there is no single-arg version of that method, unlike substring()).

More generally, there are substantial benefits in using CharSequence instead of String throughout Clojure core, not only in the context of Java interop, but also when using custom String-like data structures (e.g. ropes).

[edit] @alexmiller mentioned this in another forum (and I'm capturing it here for posterity), but this might also require that the result be stred, to ensure the return type remains unchanged (subSequence() returns a CharSequence, unlike substring, which might break callers). There may be performance implications of adding that call for types other than String (but existing callers should be unaffected, since String.toString() is identity).

Is invoking an anonymous primitive function expected to use the primitive interface?

Tue, 13 Jan 2026 14:28:41 +0000

Invoking an anonymous primitive function seems to not use the primitive interface.

(set! *unchecked-math* :warn-on-boxed)
(let [f (fn ^double [] 1.0)]
  (+ 1.0 (f)))
;; Boxed math warning

Is this expected behaviour?

Reader docs say foo.bar is a qualified symbol but qualified-symbol? is false

Mon, 12 Jan 2026 21:44:25 +0000

The reader reference on clojure.org says "Symbols containing / or . are said to be 'qualified'." but qualified-symbol? is defined to return true if the argument is a "symbol with a namespace".

Almost every reference to a "qualified symbol" in the docs (on clojure.org) refers to a "namespace-qualified symbol" or a "fully-qualified symbol" (also with a namespace).

The only other type of "qualified symbol" mentioned is on the evaluation page where it refers to a "package-qualified symbol" for a Java class name.

I suggest changing that original sentence to read "Symbols containing / are said to be 'namespace-qualified' or 'fully-qualified'. Symbols containing . are said to be 'package-qualified' if they identify a Java class name." or something similar.

Literals for Unicode code points (and perhaps also sequences thereof)

Mon, 12 Jan 2026 20:02:41 +0000

Context
For historical reasons the JVM type system's support for Unicode code points is poor, and while this is usually invisible to the developer it becomes a hassle when String literals containing non-Latin1 code points are used in code. It also becomes particularly problematic when cross-platform (cljc) code is attempting to do this, since other platforms may not share this historical oddity so solutions that "work" in ClojureJVM may break in other dialects.

For example, the transgender flag emoji (a single grapheme cluster that happens to be defined by 5 Unicode code points) cannot easily be constructed at the REPL or in a source file without detailed knowledge of the JVM's history (and associated knowledge of UTF-16, an increasingly obsolete character encoding).

Using the documented code points for this grapheme cluster with the JVM's Unicode escaping mechanism does not give the expected outcome:

The correct, but unintuitive solution is to remember that the JVM does not directly support Unicode code points in the supplemental planes, and then to translate the supplemental code point U+1F3F3 into its UTF-16 code unit / surrogate pair representation:

Note: I had to use screenshots for this, since ask.clojure doesn't appear to support Unicode supplemental code points properly either...

Question/request/proposal
Clojure can sidestep this issue in a purely accretive manner, providing better consistency across the JVM and other runtimes, by adding direct support for Unicode literals.

This would involve adding a new literal syntax that represents a single Unicode code point, and perhaps also a new literal syntax that represents a sequence of Unicode code points (perhaps supporting not only the novel Unicode code point literal, but also the existing Character and String literals). Both of these new literals would produce a standard JVM (or JavaScript, or ...) String object, in whatever native encoding those objects employ on their respective platforms - after such literals are read, it's all just the extant String data type - there is no runtime impact.

An example literal syntax

While I am not proposing a specific syntax for these new literals here (though such a task is a necessary step), for illustrative purposes here is an example of what these literals might approximately look like:

Single Unicode code point literals:

#U+0061: produces a String containing the Latin letter a: "a"
#U+1F921: produces a String containing the clown emoji (which ask.clojure cannot display)

Sequences of Unicode code point literals:

#U+[U+0061 U+0020 U+1F921]: produces the 3 grapheme cluster String: "a <clown emoji>"
#U+["a " U+1F921]: produces the same String, but demonstrates why it may be useful to support a mix of literals within the sequence (for readability)
#U+[\a \space U+1F921]: ditto
#U+[U+1F3F3 U+FE0F U+200D U+26A7 U+FE0F]: produces a String containing a single grapheme cluster (the transgender flag emoji)

This final example is an ideal test case, since the transgender flag emoji is a single Unicode grapheme cluster, defined by 5 Unicode code points, but on the JVM (for the historical reason listed originally) is made up of 6 Characters.

Note that the sequence literal may not be necessary, since str could be used with the single code point literal syntax; e.g. (str #U+1F3F3 #U+FE0F #U+200D #U+26A7 #U+FE0F). Whether shifting the cost of string concatenation from read-time to runtime matters or not is another topic worthy of deeper consideration.

Other notes
Orthogonal to this proposal (at least from a Clojure core perspective; from a user perspective they're closely related), it would also be useful if Clojure core (perhaps in the clojure.string namespace) had functions to turn Strings into sequences of code points (as integers) and vice versa. Both the JVM and JavaScript provide native APIs for doing this (and presumably other platforms do too), but providing these as standard functions in Clojure core (similar to what was done with parse-long, parse-double, and parse-boolean in Clojure v1.11) has value and is also purely accretive.

CVE-warning in org.fressian/fressian <- org.clojure/data.fressian

Fri, 09 Jan 2026 12:45:21 +0000

Dependency Information
When running clj-watson in a project with

org.clojure/data.fressian {:mvn/version "1.1.1"}

I get the following warning, refering to CVE-2018-10054 (relates to a vulnerability in H2 and its usage in older versions of datomic). I assume this is a false positive.

NAME: org.fressian/fressian
VERSION: 0.6.8

DEPENDENCY FOUND IN:

[org.clojure/data.fressian]

FIX SUGGESTION:

Vulnerabilities

SEVERITY: HIGH
IDENTIFIERS: CVE-2018-10054
CVSS: 8.8 (version 3.1)
PATCHED VERSION: Information not available.

false positive warning: "cljs.core/+, all arguments must be numbers"

Tue, 06 Jan 2026 16:51:22 +0000

The inc function below will never receive a nil, but falsely warns that it might:

clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.12.134"}}}' -M -m cljs.main -re node
ClojureScript 1.12.134

cljs.user=> (some-> 1 (#(when (pos? %) %)) inc)
WARNING: cljs.core/+, all arguments must be numbers, got [#{nil clj-nil} number] instead at line 1 <cljs repl>
2

ClojureScript :preloads doesn't work with just cljs.main --repl

Wed, 24 Dec 2025 15:13:56 +0000

Running cljs.main with just --repl doesn't preload whatever is on :preloads.

Given that the quickest way of trying ClojureScript is by running a command like :

clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.12.134"}}}}' -M -m cljs.main --repl

it would be great (and I think expected) to be able to run a repl with some dev tooling, like :

clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.12.134"} binaryage/devtools {:mvn/version "1.0.7"}}}}' -M -m cljs.main -co '{:preloads [devtools.preload]}' --repl

but it doesn't work.

It reads the file (it complains if you misspell the preload namespace) but then nothing gets loaded.

The problem seems to be related to ClojureScript not compiling the preload namespace when you run with just --repl

If you create a small single file project (like on the start guide) and then do :

clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.12.134"} binaryage/devtools {:mvn/version "1.0.7"}}}}' -M -m cljs.main -co '{:preloads [devtools.preload]}' --compile hello-world.core --repl

it works.
After the compile generates the out folder you can run just with --repl and the preload will work.

How to access non-jar artifacts (aar, zip) downloaded via tools.deps in build.clj?

Wed, 24 Dec 2025 08:55:46 +0000

I want to access an aar/zip artifact in build.clj that's already downloaded via deps.edn:

{:deps
 {com.newrelic.agent.android/android-agent {:local/root "build/jars/android-agent.jar"
                                            :doc        "extracted from aar"}
  com.newrelic.agent.java/newrelic-api     {:local/root "build/jars/newrelic-api.jar"
                                            :doc        "extracted from newrelic-java.zip"}}
 :aliases
 {:build {:deps       {io.github.clojure/tools.build            {:mvn/version "0.10.11"}
                       com.newrelic.agent.java/newrelic-java    {:mvn/version "8.25.1"
                                                                 :extension   "zip"}
                       com.newrelic.agent.android/android-agent {:mvn/version "7.6.14"
                                                                 :extension   "aar"}}
          :ns-default build}}}

In build.clj I need to unpack this zip and extract a jar from it.
And I don't have to hardcode .m2 paths or duplicate the version.

How can it be done?

See https://github.com/clojure/tools.deps/blob/46661e929ab702d0ee532188edb58d06b39cef6c/src/main/clojure/clojure/tools/deps/extensions/maven.clj#L172

Why does the REPL incorrectly display my command after I press enter?

Mon, 22 Dec 2025 15:01:06 +0000

Hello,

I'm having a small bug with the Clojure REPL - when I enter a command, after pressing the enter key, the command gets displayed incorrectly - basically the beginning of the text of the command that I entered is displayed for the first few characters, and then everything after that is overwritten with the same text of the command displayed with an indentation.

Not sure if that's very clear, so I've added a pair of screenshots, "before and after", to illustrate.

This issue seems similar to this older question, although in that case the issue was with the rlwrap library, which was patched afterwards.

Is there a way to fix this?

`(max "x" "y")` used to return "y", now it returns "x"

Mon, 22 Dec 2025 13:45:04 +0000

Hello!

With cljs 1.12.42:

cljs.user=> (max "x" "y")
"y"
cljs.user=>

With cljs 1.12.134:

cljs.user=> (max "x" "y")
"x"
cljs.user=>

Probably related to CLJS-3425 and this commit which added NaN checks:

(defn ^number max
  "Returns the greatest of the nums."
  ([x] x)
  ([x y]
   (cond
     (NaN? x) x
     (NaN? y) y
     (> x y) x
     :else y))
  ([x y & more]
   (reduce max (cljs.core/max x y) more)))

But:

cljs.user=> (NaN? "x")
true
cljs.user=>

Hence the result.

Not sure what the expected result should be since min/max are only supposed to work with numbers but current behavior is surprising.

Octal escape sequence decoding in strings does not stop at non-octal digit

Thu, 18 Dec 2025 09:35:53 +0000

Strings suppose to support standard Java escape sequences, including octal escape sequence: [0-7]{1,3}

In Java decoding of octal sequences stop at the first non-octal digit or any other character if there are 1 or two octal digits in the escape sequence. For example:

jshell> "\18"
$1 ==> "\0018"

But Clojure reads up to 3 potentially octal digits greedily resulting in wrongly consuming non-octal digits:

Clojure 1.12.4
user=> "\18"
Syntax error reading source at (REPL:1:5).
Invalid digit: 8

non-octal characters:

Clojure 1.12.4
user=> "\1d"
Syntax error reading source at (REPL:1:5).
Invalid digit: d

And succeed only when there is line terminator or exact three octal digits in supported octal range:

Clojure 1.12.4
user=> "\1"
""
user=> "\1"
""
user=> "\12"
"\n"
user=> "\123"
"S"
user=> "\123d"
"Sd"

Trying to extract vec from vec - conj not working?

Mon, 15 Dec 2025 01:53:12 +0000

I'm trying to define a function that will extract a shorter vector from a longer vector. Here is the code:

(defn vfromv [v1 v2 start stop] 
    (loop [i start] 
      (if (> i stop)
        "Stop-val exceeded"
          (do
            (conj v2 (get v1 i))
            (println i)
            (println (get v1 i))
            (if (> i 0) (println (get v2 i)))
            (println v2)
            (recur (inc i))))))

Calling the function:
(vfromv [0 1 2 3 4 5 6 7 8 9] [] 2 6)

gives the repl output:
2
2
nil
[]
3
3
nil
[]
4
4
nil
[]
5
5
nil
[]
6
6
nil
[]
"Stop-val exceeded"

It looks like the conj function isn't working but I can't see why.

Can anyone help me understand why this isn't working?

Thanks.

Aliased namespace in tagged literal

Thu, 11 Dec 2025 20:01:16 +0000

Set up

Tagged literals are defined by setting a namespaced symbol in data_readers.clj (or data_readers.cljc). At load, Clojure merges all of the maps defined in data_readers.clj(c) files found on the classpath into a single map. At read time, the symbol following a # is checked in the merged data readers map, which determines which var to call with the contents of the following form.

For example, #foo/bar [1 2 3] leads to the reader calling the equivalent of (get *data-readers* 'foo/bar).

Problem statement

The tag of a tagged literal must be determined when it is created. The namespace of the chosen tag is set and cannot be changed by a user. Unlike a fully qualified symbol with an aliased namespace, a tagged literal must what was chosen by the author.

As an author of tagged literals, I want to write tags that will not clash with other tags by giving them complex/deep namespaces. For example, {noahtheduke.lazytest/expect noahtheduke.lazytest/expect}.

As a user of tagged literals, I want to alias the namespace of tags and use it in my code. For example:

;; in src/data_readers.clj
{noahtheduke.lazytest/expect noahtheduke.lazytest/expect}

;; in test/noahtheduke/example_project/main-test.clj
(ns noahtheduke.example-project.main-test
  (:require
   [noahtheduke.lazytest :as-alias lt]
   [noahtheduke.lazytest.core :refer [defdescribe it]]))

(defdescribe some-test
  (it "works"
    #lt/expect (= 1 2)))

EDN

This is not related to edn at all and any potential change will be to Clojure itself.

`find` docstring enhancement proposal

Thu, 11 Dec 2025 12:41:48 +0000

The docstring for clojure.core/find states

Returns the map entry for key, or nil if key not present.

Formatted lower-cased with a space, it is not immediately apparent that 'map entry' is a term of art referring to a specific thing. 'map entry' might be mis-interpreted as a casual synonym for 'the entry of a map associated to a key', i.e., the value.

Proposal #1
Reword the find docstring to be more precise about what is returned.

Returns a clojure.lang.MapEntry containing key and the associated value, or nil if key not present.

Proposal #2
If you don't want to make a commitment to returning a MapEntry, reword to

Returns a sequential collection containing key and the associated value, or nil if key not present.

Why is `list` defined with a RestFn instead of `create` method?

Tue, 09 Dec 2025 15:18:48 +0000

Stemming from a conversation on slack, I learned that list is not a function created with fn* but an instance of the class clojure.lang.PersistentList$Primordial. This leads to inconsistencies, such as (vary-meta list assoc :hello :world) throwing an error instead of returning an AFunction with metadata. Reading through the git history, it looks like this approach was chosen very early (commit "made list return a PersistentList, not a seq").

Is there a reason why this approach was taken versus a create(ISeq args) overload like vector and hash-map?

not-found arg for invoking set (and vector)?

Sat, 06 Dec 2025 15:58:45 +0000

Is there a reason that sets (and vectors) don't have a not-found argument for invoke?

({:a :b} :c :not-found) ;;=> :not-found
user=> (#{:a :b} :c :not-found)
Execution error (ArityException) at user/eval1 (REPL:1).
Wrong number of args (2) passed to: clojure.lang.PersistentHashSet

In ClojureScript it's already implemented:

cljs.user=> (#{:a :b :c} :d :not-found)
:not-found

However not for vector:

cljs.user=>  ([] 0 :not-found)
Execution error (Error) at (<cljs repl>:1).
No item 0 in vector of length 0

If JIRA issue + patch is welcome for this, I'm volunteering.