Wow that `let url` example taking 10 seconds and only down to 6 seconds now is shockingly bad. As someone who recently started getting into iOS/macOS development and has noticed these wildly slow type checking times on my M2 Air, this is enough to make me reconsider if I want to invest in this platform...
No joke, that's just wild. I'd expect an expression like that to type-check literally a million times faster - at the least. Even after reading the article, it's not clear why that particular expression is so egregiously poor.
> The Swift standard library has 17 overloads of + and 9 types adopting the ExpressibleByStringLiteral Protocol. This leads to an exponential combination of types and operators for the constraint solver to try.
I think the ExpressibleBy thing means that a string literal can be interpreted to mean any of those 9 types. Personally I agree with you; I would actually suggest that the compiler error out if there are anywhere near this many interpretations of an expression. Apparently the corrected expression compiles in 0.19s, which is unacceptable to me. I would much rather pay the cost once of adding a few type annotations or intermediate expressions than pay that fifth of a second over and over and over again for every recompile of that file. Since the types a pretty global constraint system, the expression is a landmine as well: you could fiddle with some distant overload which causes it to attempt the permutations in a different order and suddenly start timing out again.
I would rather just have a flag to require type annotations to simply not have to worry about this. I find code much harder to read without them anyway.
It is pretty rough but as someone who has been programming in Swift since 1.0 I can say it rarely happens in practice. In the early days it happened all the time where the compiler would trip up on random expressions. I can still get it to happen, especially on complex closure type things, but even if those did compile they're confusing enough where they really shouldn't make it past code review anyway. That url example should never either.
I am very curious as to what you're running into where you're seeing wildly slow type checking times.
Same here. I rarely run into this problem. I write mostly SwiftUI too. I will admit there are some built in SwiftUI views that are problematic: tables, outline groups.
The issue with Swift IS the type theory. Constraint solvers are by definition going to be harder to reason about and have longer execution time than just declaring the type.
