
Inline types and functions in Swift - ingve
https://www.swiftbysundell.com/posts/inline-types-and-functions-in-swift
======
saagarjha
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).

~~~
jordansmithnz
Yeah, I’ve noticed that too for complex closures.

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).

------
andrekandre
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 ^_^;

[edit: fix grammar]

------
judge2020
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.

~~~
saagarjha
Xcode does, at least. I'm sure there are ways to coax SourceKit into giving
you this information if you'd like to use it in another IDE.

