@U050B88UR I agree that it's an edgecase, I'm just suggesting that it's a legitimate one – I mentioned some examples in the linked thread. My expectations are pretty straightforward – I would like this...:

(letfn [(f [] ...)
        (g [] ...)]
  (defn h [] (f) (g)))

(let [f (fn f [] ...)
      g (fn g [] ...)]
  (defn h [] (f) (g)))

...plus a mention in the docs, maybe on the Differences from Clojure page.

Cause this part...: > The following ClojureScript special forms are identical to their Clojure cousins: if, do, let, letfn, quote, loop, recur, throw, and try. ...ain't exactly true right now.

I could open a PR for the documentation.

Just a final note on how common top-level closures with nested defns are. Looking through the results of path:*.clj? /^\(let/ /^[ ]{2,}\(defn-?/ https://github.com/search?q=path%3A*.clj%3F+%2F%5E%5C%28let%2F+%2F%5E%5B+%5D%7B2%2C%7D%5C%28defn-%3F%2F&type=code shows them being used in projects like fulcro, electric, malli, specter, figwheel, timbre, core.typed, quiescent, sicmutils, parsesso, rewrite-clj, membrane, datahike, truss, and many more. Fulcro, sicmutils and parsesso in particular use top-level letfns with many of those usages being in ClojureScript namespaces. If we extend the search to include (do (defn ...) ...), (if ... (defn ...)) and other real-world nested usages of defn, the number of results blows up and includes Clojure/ClojureScript itself. Looking at all this and also taking the already mentioned Clojure documentation into consideration, I'm actually inclined to go back on my initial agreement that any of this is an edgecase – I don't think it is, despite being much less common than the regular top-level usage of defn. I rest my case, prosecution has the floor. :)

P.S. I should perhaps also summarise my reasons for using top-level closures in general, which I suspect other users of them will agree with: a) by acting as local constants of sorts, they can improve performance by letting me evaluate the bound expression only once instead of on every function call, and when that binding is very specific to a particular defn I don't want to pollute the namespace by def-ing it. and b) when the expression is an anonymous function, having it outside the defn makes things much more readable.

I’ve used this pattern as well (let around a defn) and I was not the one to come up with it. Pretty sure I picked the idea up out of a clojure book…don’t remember which one, but pretty sure it was a published one. The author was making the point that if you needed something more private than private (didn’t want to pollute the ns itself) that it was arguably better. I look at it from the dynamic language philosophy of clojure (though I know that Clojurescript is just trying to be “close, not exact), and see no philosophical reason for it not to work. I agree that there may be implementation difficulties. They are two different things.

At the very least the compile should do one of: • Not accept constructions that will not compile to correct code • Issue a warning that such a construct isn’t supported and should be rewritten • Accept it and provide a working implementation

Also, there are tons of examples of emitting let around a def in macro writing. For example page 236 of “Programming Clojure” from May 2009. So, it seems like a reasonable thought process to expect that if something like:

(let [f (fn [...] ...)]
  (def foo (fn [ ... ]  code that uses f)))

(letfn [(f [...] ...)]
  (defn foo ...))

In fact I would argue that macros are the go-to case for where top-level let-like closures around defs make sense: I should not be emitting top-level symbols into a ns that are “implementation details” if I can avoid it.

just FYI, letfn may have different semantics than let [_ (fn when multiple functions are defined, because of the forward declaration of bindings of letfn (by design)

but yes, in general they should be equivalent modulo forward references

Yup, this was already acknowledged above: > [...] ...with the added ability for f to call g. > I understand that due to the support for mutual recursion letfn is more than just syntactic sugar for let [...]