"The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" Caused by '+' op on Text() View

Inside my view's body mix in many other views, lines like this cause the compile error:

Text("Tax").foregroundColor(.secondary) + Text("\(self.taxPercent, specifier: "%.2lf")%")
Text("Tax").foregroundColor(.secondary) + Text("\(self.taxPercent, specifier: "%.2lf")%")

If there is only one line like this, compile...more than one, error...

What can I do to help the compiler?

The + operator must be too overloaded for the compiler to deal with inside the little bit slightly complicated view build.

I just call my own func instead:

func concatenate(_ lhs: Text, _ rhs: Text) -> Text {
    return lhs + rhs

problem solve....

1 Like

SwiftUI is still in beta and therefore the compiler can sometimes give you very confusing or even wrong error messages. So I personally check all my code for mistakes when there's an error regarding SwiftUI.
I just wanted to say look out for mistakes in SwiftUI because at first I was really confused with the error messages.
Anyways, I'm glad you solved the problem on your own!


I'm not sure that SwiftUI should have added even more overloads for +, given the performance issues with the current set of overloads in the standard library.


This is not only a problem with SwiftUI and/or beta versions of Swift. Confusing or wrong error messages related to type inference are a very common occurrence in highly generic Swift code, unfortunately.


5.2 all okay now, compile really fast and no more error! Compiling several Text() + Text() used to go on forever and fail...

Thanks for the great work, Swift...er...Swifties?


These type checker issues have existed for quite some time and it's very frustrating, for example: When making extensive use of the SIMD types, you have to break up your code into almost one operator per expression, or you'll have compile times that increase exponentially with the (type-checker-perceived) "complexity" of those expressions.

Until this is fixed, we have two options:

  1. Help the type checker by writing unnaturally chopped up code, or
  2. Wait (for the type checker to slowly process your natural code (and for the type checker issue to be fixed)).

Depending on the type of code and size of your codebase, and whether you have to compile often with optimizations (especially -whole-module-optimization) or not, option 1 can be the less frustrating.

Using various compiler flags (set for your target's "other swift flags") can help you identify what code you should focus on helping the type checker with, eg:

-Xfrontend -warn-long-function-bodies=150

There's plenty to read on the internet about these things. Here's the result of a quick search.

But perhaps there's a more official document somewhere (including all relevant compiler flags, up to date suggestions for workarounds, status and roadmap for fixing the issue, etc)?


There must be some improvement to make my problem go away. Would like to know what the improvement is...surely must be improvement to type inference?

But I do see now very often "the build system has crashed, close and open you workspace" (something like this).