Hmm, no… hoisting or forward referencing is not that difficult concept to wrap your head around it, and it certainly isn’t new thingy on the block… It has known scope and the only thing hoisting does is allow your code to call (local) function which is defined later further down in the scope of the parent func().
As you’ve noted:classes have the same issue, especially with lateinit keyword, and the program can crash if you’re doing silly things. Yet, quite differently to Local Functions, it is allowed. By arguing against hoisting you note that it is alive, well and not misused in other parts of Kotlin!
Moreover your negating that it’s easily done has been refuted a couple of times by noting that:
fun proxyFunc() = showA()
fun showA() = println(a)
works on toplevel, just not while they’re Local Functions.
Language design can, and maybe should, handhold beginners to warn them about weird usage, but it definitively shouldn’t limit non-beginners to do what they know is safe. This is why Linting tools have “suppress” functionality in them…
@vngantk understood what is missing from Local Functions way before this topic, as did I and probably others. Allowing hoisting of Local Functions enables writing cleaner code by allowing programmer to use concept of functional decomposition. To define more detailed code after more generic code, so that it reads naturally when someone reads/maintains it.
Using Local Functions as helper methods does not void using them for closures, that was a weak argument against them. Yet limiting forward referencing by language design because someone may not understand their scope is equally weak argument against them. Especially, for the n-th time, since the same “problem” exists for toplevel functions and in classes but hoisting is not only allowed, but done, in Kotlin…