The threading macro replacement rule suggests inequivalent forms

[tsdh]

The threading macro replacement rule suggests inequivalent forms

[tsdh]

Here's a very related occurence.

[91] Consider:
  (.add (.getContentPane) (JScrollPane. label))
instead of:
  (-> (.getContentPane) (.add (JScrollPane. label)))

While this looks correct when viewed isolated, it's wrong if you check the complete context:

(doto frame
   (-> (.getContentPane)
        (.add (JScrollPane. label)))
   (.setDefaultCloseOperation WindowConstants/DISPOSE_ON_CLOSE)
   (.addKeyListener ...))

As you can see, frame will be injected as first form into the threading form by the doto. With the suggestion, frame would be injected into the (.add #_frame-would-end-up-here (.getContentPane) (JScrollPane. label)) form and render it invalid.

[jonase]

In general, I think this is a fundamental limitation of kibit. Since kibit reads the source without macroexpanding it first it's easy for a macro to invalidate a rule.

[tsdh]

Yes, after thinking about it, I came to the same conclusion. Anything that's nested inside some macro can be transformed to possibly anything.

Would it be possible to restrict kibit to forms that aren't inside a macro or only inside some whitelisted macro we know it won't restructure the code in inexpected ways (like defn, fn, do, when, ...)?

[danielcompton]

@tsdh because we don't evaluate any of the code in Kibit, I don't think we can know which forms are inside a macro or just another users function. I'm closing this for now as I don't think there's any way to get around this, but I'd be happy to hear if there is.