> This has tradeoffs: increased ABI stability at the cost of longer compile times.
replyNah. Slow type checking in Swift is primarily caused by the fact that functions and operators can be overloaded on type.
Separately-compiled generics don't introduce any algorithmic complexity and are actually good for compile time, because you don't have to re-type check every template expansion more than once.
A lot can be done by the programmer to mitigate slow builds in Swift. Breaking up long expressions into smaller ones and using explicit types where type inference is expensive for example.
replyI’d like to see tooling for this to pinpoint bottlenecks - it’s not always obvious what’s making builds slow.
>I’d like to see tooling for this to pinpoint bottlenecks - it’s not always obvious what’s making builds slow.
replyI second this enthusiastically.
I'll third it. I've started to see more and more cargo culting of "fixes" that I'm extremely suspicious do nothing aside from making the code bulkier.
reply> Breaking up long expressions into smaller ones
replyIf it improves compile time, that sounds like a bug in the compiler or the design of the language itself.
>This is unlike C++ templates which are effectively copy-pasting the resolved type with the generic for every occurrence of type resolution.
replyEven this can lead to unworkable compile times, to the point that code is rewritten.