I generally tend to write inline functions as closures, which I feel are a bit more flexible (you can assign to them, for example) and syntactically lightweight. One thing to note is that closures cannot have generic parameters, so you will have to write a function in this case. Another annoyance I have with closures is that they require explicit annotation of their result type if you use them to encapsulate complex initialization; I’m still convinced that the compiler does know the actual type but forces me to put it there to spite me (or, more likely, it’s required for clarity).
In general Swift’s type inference can be slow, and seems to have bad time complexity. I suspect that for non trivial closures Swift falls back to requiring explicit typing so that type inference speed doesn’t become too much of an issue.
You can actually improve compile times somewhat by adding explicit typing for complex statements. There’s a compiler flag for logging compile time per function, and for large projects I’ve used this to identify and add typing for problematic lines (sometimes these lines each contributed to a few seconds of compile time).
i’ve found that too much in lining, especially with a lot of inline closures can throw testability out the window, but the examples here are pretty good as each example is showing how to recompose each function for clarity and usefulness, not turning them into huge inline monstrosities, of which i am all too familiar ^_^;
Inline type definitions are great, but hopefully the IDE has ctrl-click functionality that will take you to the type definition when you want to see it.
