Clojurians Log v2
clj-kondo 2026-04-28
It's by design that (let [{:keys [::foo/bar]} {::foo/bar 1}] bar) is allowed right?
https://github.com/clj-kondo/clj-kondo/issues/2808 seems to want to forbid even those kinds of keys in key destructuring. not sure why anybody would want to do this, but feedback welcome.
not sure if relevant, but clojure core has some https://github.com/clojure/clojure/blob/dd395eaa400767e5579ccd674627664c5c3d33da/test/clojure/test_clojure/special.clj#L43 for that
that is relevant!
I am always a bit vary of the tests in core as although they codify some behavior it doesn't always imply that behavior is something to lean on or use in actual code. for example the https://github.com/clojure/clojure/blob/dd395eaa400767e5579ccd674627664c5c3d33da/test/clojure/test_clojure/data_structures.clj#L1334 🙂
deliberate features are still worth having a linter to deny, right?
It is intentional, for auto resolved keyword key destructuring, later superseded by ::foo/keys or ::keys which I generally prefer, but can be useful when destructuring kws of mixed namespaces
imo, would not lint it, its perfectly ok
i don't mean for a default on linter, but specifying which style of :keys are or are not allowed would be nice for consistency
on the other hand if clj-kondo allows overspecific preferences, the community as whole would be less consistent :)
How would you feel if clj-kondo suggested cond-> here?
https://github.com/overtone/overtone/blob/eb531784b32737b90a44576b169934c3553d817d/src/overtone/libs/handlers.clj#L45
Overtone example is pretty clear where cond-> would make sense, but I think I've used the pattern somewhere where I specifically like the let and if better.
BUT likely those cases are I'm doing something "more" compared to the Overtone code.
E.g. in this let block I would keep the ifs because there are a few let bindings between those ifs. Like line 565 and 576: https://github.com/yaml/yamlscript/blob/v0/ys/src/yamlscript/cli.clj#L566
And in many of those examples, I kind of like the if version when there is something else on the let anyway, like the re-frame-10x example.
https://github.com/yqrashawn/GokuRakuJoudo/blob/master/src/karabiner_configurator/conditions.clj#L40
This file uses the pattern for both rst on the line 40 and then result on the upper for :let binding.
On the for :let binding I think the if pattern works better as there are several other things between those ifs, though there are a couple if in succession (lines 63-89).
Would clj-kondo suggest replacing that whole sequence of let bindings with a single cond->? If so, I'd say, "yes, I'd like this linter".
(just read the issue and, yeah, this is specifically about multiple conditional bindings building a map)
those kinds of repeated bindings were the exact shape that led me to learn about cond-> in the first place (from a code review from a more experienced dev). I think that'd be great if kondo could nudge people to the same insight.
I see 2 different outcomes: 1. replace the individual ifs with cond->, keeping the repeated bindings 2. one cond-> chain Both have their places and IMO both are better than what's there atm. An if that either returns a thing or "modifies" that same thing is worth a cond->/->> in my book
in projects with medley, I'd prefer assoc-some for the overtone example.