This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-14
Channels
- # adventofcode (6)
- # announcements (4)
- # babashka (11)
- # beginners (18)
- # cider (7)
- # clj-kondo (4)
- # clj-on-windows (32)
- # clojars (6)
- # clojure-doc (1)
- # clojure-europe (14)
- # clojure-sg (1)
- # clojurescript (24)
- # conjure (4)
- # cursive (14)
- # datomic (2)
- # events (2)
- # graphql (5)
- # meander (6)
- # missionary (10)
- # nextjournal (6)
- # off-topic (10)
- # pathom (2)
- # pedestal (1)
- # practicalli (1)
- # re-frame (8)
- # reagent (3)
- # releases (1)
- # sci (6)
- # shadow-cljs (10)
- # spacemacs (4)
- # vim (6)
- # xtdb (9)
Morning
So glad to be actually able to greet you in the morning now. It's good to be back.
You call the fn with the wrong arity, and clj-kondo is not there to help you, because it’s nothing it can do.
Ah, but no, and I’m not blaming clj-kondo here, only myself:
(defn foo
([one] ...)
([one two] ...))
Now when I call
(foo 1)
rather than (foo 1 2)
as I should have done, clj-kondo can’t help me.
A bit lik when you call (map bla)
and you get a transducer rather than your mapped seqah yes, but with the transducer stuff clj-kondo does actually help in some cases :)
e.g. (first (map inc))
gives a warning
wrt to mult-arity fns - the usual answer is passing a map - the map can be spec'ed and / or checked with :pre
... still can FU though :man-shrugging::skin-tone-3:
One thing I haven't pondered much is that we tend to not recommend fns which change their return type depending on the params. But all the transducer fns in core do exactly that.
Rules are meant to be broken, when a strong argument for just that arises 🙂