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...
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...
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.
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.
The paper The Simple Essence of Overloading: Making Ad-Hoc Polymorphism More Algebraic with Flow-Based Variational Type-Checking, should help with the overloading part hopefully
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”.
Swift is an early example of Apple losing its way. Such a stark contrast to Objective-c -- which was a simple, fast compiling language that hit way above its weight for expressivity and runtime speed. A great language for its day. Swift is "a C++ hacker's first attempt at language design".
I love the clean syntax of Swift, which allows you to omit a lot of syntactic noise. It's so much nicer to write and read than for example Rust with it's ugly wordiness. But the type checker performance really is inacceptable.
it seems like the clean syntax makes the type checker's life harder and so performance is unacceptable. would you rather have clean syntax or acceptable compile times?
Every time I tinker with languages like Rust or Crystal or Swift, I am amazed by their compilation times. OCaml and Pascal got this right aeons ago. I’m looking forward to a public release of Jai simply because compilation speed is one of its primary motivations. Having a fast feedback loop is crucial to my adhd-like development workflow.
> The invalid expression from above, where + was applied to String and Int, is still rejected, however with the new algorithm, it only takes the compiler 2 seconds to reach the limit.
I think failing is okay, as the expression can then be explicitly typed. But if it would be solved slowly by the type checker, does Xcode show a slow compile warning for the line that this code should be optimized?
> However, an integer literal such as 123 actually has two default types, Int and Double, and the resulting disjunction has three choices. It might be worth considering a language change where floating point literals must be spelled with a decimal point. Today, expressions involving mixed integer and double literals can be particularly tricky to type check, for this reason.
The habit to write 123.0 for floats is second nature. I think this is a good idea, don’t know if other programmers would find that annoying? (aside the annoyance of changing existing code bases).
Kotlin, which has very similar syntax and language goals as swift, though a different runtime of course, does it also suffer from long compilation times for some expressions due to type checking?
16 comments
[ 4.0 ms ] story [ 41.4 ms ] threadI am very curious as to what you're running into where you're seeing wildly slow type checking times.
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.
So, something like "How to make ad-hoc polymorphism less ad hoc"?
Smells like “we made a poor architectural / design choice and ain’t walking it back”.
Oh how I wish I could have a working Swift :(.
> The invalid expression from above, where + was applied to String and Int, is still rejected, however with the new algorithm, it only takes the compiler 2 seconds to reach the limit.
I think failing is okay, as the expression can then be explicitly typed. But if it would be solved slowly by the type checker, does Xcode show a slow compile warning for the line that this code should be optimized?
> However, an integer literal such as 123 actually has two default types, Int and Double, and the resulting disjunction has three choices. It might be worth considering a language change where floating point literals must be spelled with a decimal point. Today, expressions involving mixed integer and double literals can be particularly tricky to type check, for this reason.
The habit to write 123.0 for floats is second nature. I think this is a good idea, don’t know if other programmers would find that annoying? (aside the annoyance of changing existing code bases).