Nick Lockwood

This was an interesting read: https://danielchasehooper.com/posts/why-swift-is-slow/

Coupled with the generally terrible compile times in Xcode, this can make Swift dev a miserable experience sometimes - especially when using SwiftUI, which exacerbates the problem with its heavy reliance on inference and overloading

I think the Swift team maybe underestimates how big of a problem this is? From this thread it seems like it's been written off as unsolvable rather than being an area of active effort?

https://forums.swift.org/t/replacing-the-type-checker/79518

Why Swift’s Type Checker Is So Slow

How a 10 year old design choice for Swift’s type checker still haunts us to this day

Jun 3, 2025 at 6:58amWeb
Show threadJan EkholmJun 3, 2025

@nicklockwood Having to comment out large parts of a View in order to get the compiler to find a real error is really annoying. Usually it's a wrong/missing parameter somewhere, but in a large View it's hard to find without any support from the compiler.

Edit: typo

Show threadKyle HughesJun 3, 2025

@nicklockwood Is your type checker running?

Then you better go catch it!

Show threadHannes OudJun 3, 2025
@nicklockwood I often feel like there should be a tool that automatically adds (either in source code or a cache) type annotations after slow inferrances to speed them up the next compile, so at least the „work“ is only done once.
Show threaddimsumthinkingJun 3, 2025
@hannesoid @nicklockwood @axel change automatically adds to offers to add and I agree
Show threadAdrian Schönig Jun 3, 2025
@nicklockwood What the heck those comments... Fighting the type checker is a regular frustration when working with non-trivial SwiftUI views. New in Swift 6 is that I also have to please the compiler with all the new concurrency-related refactoring. Shouldn’t Swift be a language and tool set that helps developers do their job and be productive rather than whatever this is becoming?
Show threadSlava PestovJun 3, 2025
@nicklockwood I landed some optimizations last year that are now in the release/6.2 branch, of the "spend less time on each overload choice" variety. Someone else is working on another set of changes of the "consider fewer overload choices" variety, it didn't make the release branch cut this time around unfortunately: https://github.com/swiftlang/swift/pull/79461 The latter will fix a bunch of these silly "math operators and literals" expressions that are too slow today.
Show threadJon889Jun 4, 2025
@nicklockwood I wish the swift team would take some pointers from how Jetbrains makes Kotlin and interacts with, and are themselves, Kotlin developers.