I've noticed that the compiler (both real-time analysis and actual compiling) gets sluggish and unreliable over time when a project grows. I think I've found the source of the problem and unfortunately for people in large code bases it does take a bit of rewriting to get it back into shape.

Since the language is very strictly typed yet allows for a loose syntax, the compiler needs to guess which type you are actually using. For example the type Any? always works but perhaps you are declaring it like a dictionary that always uses a string as a key? It doesn't know until it analyzes all keys and sees that you're indeed always using a string as an index. Put one Int in the end of a long list and it breaks.

Now something like this doesn't hurt:

    let indexOfTab = 4

Because the compiler sees you're trying to put an int in a constant.

But this is a bit more difficult:

    let tabDict = [ /* long list of declarations here */ ]
    let indexOfTab = tabDict.first(where: { key, value in value == "contacts" })?.key ?? 0

First it needs to know if that tabDict indeed would have only Ints or similar values as keys and only strings as values because they would now need to match what happens in the filter.

This makes the complexity of the code to analyze explode in a way that if your code consists of many of these things you all of the sudden find your computer go to a crawl.

The alternative however is a bit more ugly (I could use a bad word to describe it, like: "Java"):

   let tabDict: [Int: String] = [ /* long list of declarations here */ ]
   let tabWithContact: [Int: String] = tabDict.first(where: { key, value in value == "contacts" })
   let indexOfTab: Int = tabWithContact?.key ?? 0

(bear with me, this code is not checked in Xcode, just a hasty example)

Now step by step the compiler does not have to guess anymore, if the first line doesn't compile (because for example you've added a string as a key) it just won't compile. Same goes for the filter function, if you treat the types wrong inside the filter block. Also not too much to guess in the third line, it will never guess what type the key is let alone compile if you would declare indexOfTab as a String.

What I would like to see is:

* A tool that can actually show the points where your code is slowing down the compiler a lot

* A tool that proposes you to split the declarations up for faster execution just like you can automate much of the changes after upgrading to a new version of Swift

All I do now is guessing and adding more code to get performance back to acceptable levels.