Imagine for a moment that you are a programmer with reasonable experience in Objective-C, who, upon having been pitched the benefits of Swift for far too long by now, decides to finally get one’s feet wet with it.

Out of all the attractive aspects of Swift there is one in particular, that piqued your interest: Type Inference.

You loath having to type the same redundant type declarations over and over again. Type Inference sounds almost too good to be true for you. You’re stoked.

You open “The Swift Programming Language” and scroll down to the chapter on “Type Safety and Type Inference“, which reads as follows:

Swift is a type-safe language. […] Because Swift is type safe, it performs type checks when compiling your code and flags any mismatched types as errors. […] Type inference is particularly useful when you declare a constant or variable with an initial value. […] For example, if you assign a literal value of 42 to a new constant without saying what type it is, Swift infers that you want the constant to be an Int , because you have initialized it with a number that looks like an integer:

Now with the meaning of life at your disposal you tell yourself, ”I might just as well do something with it”

You open up a playground: UltimateQuestion.playground and ponder about what to do next.

Being of the cautious kind you decide to go the safe route and validate your answer before using it elsewhere:

Your plan is to put the calculation of aforementioned answer ( 42 ) in a closure (you really like closures, and I can’t blame you!), so you type:

Happy with your work you hit compile.

error: unable to infer complex closure return type; add explicit type to disambiguate

You are confused. While you would have wholeheartedly agreed upon the whole “Question of Life, the Universe, and Everything” being of a rather complex matter, you’d have expected your answer ( 42 ) to it to be of a rather trivial nature.

Not willing to give up on the idea of “type inference“ already, you decide to not follow Swift’s advice, and instead simply change your closure to this:

This time Swift accepts your answer without complaints.

While still none the wiser you decide to just play along while things seem to work.

So, with all parts “working” now you would just have to pass one to the other, and Bob is your uncle, right?

Right? … Well, no.

error: cannot convert value of type ‘Int’ to expected argument type ‘UInt’

“Fine”, you say, “I’ll just pass it in by value then.”

This works. But you would actually like to avoid magic numbers in your code, and thus end up changing it to this:

Which promptly leads back to this:

error: cannot convert value of type ’Int’ to expected argument type ‘UInt’

“Oh no, not again …”, you mumble.

After a quick consideration you decide to skip the validation and just use your answer unchecked.

In order to avoid having to re-calculate it over and over again in the future you decide to at least cache your answer:

Should be as simple as that:

Things are looking fine so far. You are happy, Swift is happy.

Having invested quite a bit of time into the calculation of your answer however, you come to think “I better be prepared for additional answers, in case those come up, all of a sudden”, and change your code to:

Promptly followed by an unexpected *Slap!* to the face:

error: empty collection literal requires an explicit type

“Fine, I’ll add some type then.”, you think to yourself:

*Slap!*

error: cannot convert value of type ‘ Int ’ to expected argument type ‘ UInt ’

“Alright”, you think to yourself, “raw literals and validation via map and plain old literal-inferred Int s it is then.”:

*Slap!*

error: unable to infer complex closure return type; add explicit type to disambiguate

You decide to give it one more try. But as someone seems to have cast a spell on precious 42 you decide to give 43 a go this time:

*Slap!*

error: Binary operator ‘+’ cannot be applied to two ‘Int’ operands

“What? Now this is just getting silly.”, you mumble.

Having gone through your third coffee by now you come to the conclusion that your precious answer maybe just is of no practical use at all, and decide to call it a day and embark in something more fruitful for the rest of it.