4 ms·

My biggest gripe with type inference is compile time performance (in regards to Swift especially). When I'm writing hundreds of lines of frame layout code, I h

My biggest gripe with type inference is compile time performance (in regards to Swift especially). When I'm writing hundreds of lines of frame layout code, I have to explicitly write `let transientValue:CGFloat = ...` hundreds of times or else the compiler quits on me saying that it was unable to infer the required type before timing out. The error makes sense if you think about what the compiler is doing (solving a system of equations with all of the number like built in types) but frankly it's unnecessary to begin with. Compiler performance aside, it also makes working on code a lot heavier since the editor needs to be able to infer the types (something the full blown compiler struggles to do given all cores and tens of seconds!) before it can give sane autocomplete suggestions. I'm not sure if a better IDE than Xcode could handle this better but I've found the tools have forced me to be explicit just so I can get my work down more quickly.

seanmcdirmid 7y ago
That sounds like a very bad type inference implementation. Local type inference should fail fast.
bjz_ 7y ago
Yeah, type inference shouldn't really take a huge amount of time like that - for example Rust's type inference is a pretty small part of the overall compile time (although it can take longer if you do some crazy stuff with traits). In Swift's case it seems like they've tried to add very flexible type inference (leaving off lots of stuff) to a very flexible type system (with inheritance, overloading, protocols, etc.). This is something that academics have been aware for decades causes problems with type checking performance. Similar problems have caused the designers of Scala 3 to go back to the drawing board to redesign the type system from the ground up, with a clearer formal semantics. I do know that the Swift team are working really hard to make on demand editing/compiling better, but I don't know how far that work has come. Hopefully that improves things over time!

seanmcdirmid 7y ago

That sounds like a very bad type inference implementation. Local type inference should fail fast.

bjz_ 7y ago

Yeah, type inference shouldn't really take a huge amount of time like that - for example Rust's type inference is a pretty small part of the overall compile time (although it can take longer if you do some crazy stuff with traits). In Swift's case it seems like they've tried to add very flexible type inference (leaving off lots of stuff) to a very flexible type system (with inheritance, overloading, protocols, etc.). This is something that academics have been aware for decades causes problems with type checking performance. Similar problems have caused the designers of Scala 3 to go back to the drawing board to redesign the type system from the ground up, with a clearer formal semantics. I do know that the Swift team are working really hard to make on demand editing/compiling better, but I don't know how far that work has come. Hopefully that improves things over time!