This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-09
Channels
- # announcements (12)
- # babashka (22)
- # beginners (17)
- # boot (6)
- # calva (45)
- # clj-kondo (17)
- # clojure (70)
- # clojure-australia (4)
- # clojure-europe (35)
- # clojure-finland (6)
- # clojure-losangeles (2)
- # clojure-nl (1)
- # clojure-uk (2)
- # clojured (26)
- # clojurescript (10)
- # conjure (1)
- # datahike (1)
- # events (1)
- # honeysql (14)
- # introduce-yourself (5)
- # jobs (5)
- # joyride (2)
- # minecraft (6)
- # off-topic (5)
- # pathom (14)
- # rewrite-clj (1)
- # shadow-cljs (13)
- # tools-build (6)
- # tools-deps (13)
- # vim (29)
- # xtdb (8)
how can I disable warning for unused imports? have user.clj
with:
(ns user
(:require [integrant.repl :refer [clear go halt prep reset reset-all]]
[integrant.repl.state :as state]))
, which causes (for all of the unused ones):
... warning: #'integrant.repl/clear is referred but never used
This would probably be more obvious if I had a dependency that provided a clj-kondo config as I could see what the steps are doing but do steps 3 and 4 of the https://github.com/clj-kondo/clj-kondo/blob/master/doc/config.md#importing section only need to be done with a dependency changes? Results of both committed to your own repo or only step 3?
Has there been a lint considered for putting type hint for return values of protocol definitions on the arglist instead of on the method name like you're supposed to do?
@suskeyhose There is a linter which does this for normal functions - perhaps it already works for protocol implementations? not sure
yeah, but it has kinda the opposite requirement
(defn blah ^return [arg1 arg2] ...)
(extend-protocol Blah
Type
(^return method [arg1 arg2] ...))
@didibus already posted an issue about this. References to official Clojure docs would be useful and then we can make a linter
Sounds good
deftype and defrecord inline method impls for sure
probably reify too
http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/deftype
Method definitions take the form:
(methodname [args*] body)
The argument and return types can be hinted on the arg and
methodname symbols.
not sure what happens with extend-... - those get expanded into extend calls which don't really have the method name as a symbol anymore, not sure if that type hint is retained anywhere, probably not by just glancing at the code
I guess there's not really any need for protocols, only for Java interfaces to satisfy the type gods