3 ms·
Here's a good blog post on the issue: https://danielchasehooper.com/posts/why-swift-is-slow/ https://danielchasehooper.com/posts/why-swift-is-slow/
by aapoalas 2y ago
Here's a good blog post on the issue: https://danielchasehooper.com/posts/why-swift-is-slow/ https://danielchasehooper.com/posts/why-swift-is-slow/
- johnisgood 2y agoYeah I have read this not long ago, it is a great post. > A different approach to type checking is required to fix it. I agree, are they actively working on this though?
- int_19h 2y agoI don't see what they can do about this in general, short of requiring sufficient explicit type annotations to mitigate the combinatorial explosion of possible combinations. But if that is an acceptable solution, you can already add such annotations to your code regardless. C# actually has a similar issue with lambdas passed to generic functions, for similar reasons. It's just what you get when you combine overload resolution with type inference.
- alkonaut 2y agoOk after reading that I'm still amazed by the mistake. Surely it must have shown up before Swift was even generally available? And surely having even ONE case take several seconds for a single expression should have sent it back to the drawing board? Something still seems strange. I can imagine people start linting to require (TypeName.Membername) instead of just (.MemberName) because they hope it can speed up compilation. And at that point it again feels like a big mistake to have allowed it from the beginning.