I was thinking about a new linter that might be interesting for others as well. It would give a warning on a function that is using bang functions and if its name is not ending with an exclamation mark. This would trigger a warning:

(defn something
  (swap! atom inc))

(defn something!
  (swap! atom inc))

such linter might get very annoying in case you have a stack of multiple function, one calling another.

(defn baz []
  42)

(defn bar []
  (baz))

(defn foo []
  (bar))

(foo)

(def x (atom nil))

(defn baz [] ;; warning here
  (reset! x 42))

(defn bar []
  (baz))

(defn foo []
  (bar))

(foo)

;;; after fix

(def x (atom nil))

(defn baz! []
  (reset! x 42))

(defn bar [] ;; warning here
  (baz!))

(defn foo []
  (bar))

(foo)

yes, true, but I was thinking about enabling this for a certain namespace, like DB models

and not enable for the whole app

yeah, I see how and where this might be useful. But even within a single namespace the problem with a sudden new warning after fixing another might happen.

yes, definitely there is an avalanche effect, but for a DB model namespace, I believe that would be even favorable

A bit like java's checked exceptions, but opt in eh?

haha, kind of, yeah 😅

poor man's effect system

> such linter might get very annoying in case you have a stack of multiple function, one calling another. Sounds like a feature, not a bug when a function deep down in the call stack turns side-effecting 😄

How does that behave with a higher order function? I’m guessing static analysis would miss that, right? (defn f [f-bang] (f-bang 7)) (defn f! [n] (println n)) (f f!)

Yeah, but in that case the mutating function is the argument, not the caller.

(do (f f!) (f str))

You don’t want to rename the map function to map! just because it can receive a mutating fn

Yeah, I was thinking that too. So calling non-bang functions can side-effect :thinking_face: