Roadmap for Improving the Type Checker
6 comments
·October 31, 2025an0malous
foobazgt
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.
foobazgt
Slava mentions both bidirectional inferencing and overloading as two of the big culprits.
I've been doing some language work recently, and I'm quite sympathetic to bidirectional inferencing. I think, though, that modern PLs need better solutions for adhoc overloading. It's notorious for its complexity, blowing up algorithmically, and confusing users with surprising results (why oh why did the compiler select this function over the one I intended). That said, I haven't discovered a good alternative (for my purposes) yet.
indemnity
As someone who started doing SwiftUI recently, it absolutely boggles my mind that (1) this is even a thing and (2) Apple seem ok to treat it as an unsolvable problem. When you finally solve it is some stupid wrong type passed in somewhere. I agree with the other poster. This is so pathetic it makes me question the competence of the engineers working on Swift.
Smells like “we made a poor architectural / design choice and ain’t walking it back”.
SurceBeats
About time! Nothing kills productivity like waiting 30s for the compiler to tell you it can't infer a type on line 27437 (who needs to refactor?). The diagnostic improvements alone will be worth it really but...
bestouff
Going from 10s down to 6s is not nearly near sufficient to me. This should be instant.
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...