The same could be said for the similar C# and .NET features. The practical use for many low level constructs is for library authors, which is perhaps 1 developer out of 1000, but those libraries are used by the 999 others which means the "practical use" of the feature is a lot more than it would seem at first sight.
> Meanwhile the compiler still can't compile many even mildly complex SwiftUI views and expressions with the "The compiler is unable to type-check this expression in reasonable time" error.
That seems like a bug in language design? What's the story behind that? Did they inadvertently make something that was quadratic or worse and then realized it was too late or too fundamental to fix it properly so they patched it over with an error message?
Yes, it has to do with how its type inference interacts with certain language features (particularly return type overloading).
It's unfortunate but I would honestly be ok with a "strict mode" that requires extra annotations from the programmer if it would prevent this stupid error in practice.
> That seems like a bug in language design? What's the story behind that? Did they inadvertently make something that was quadratic or worse and then realized it was too late or too fundamental to fix it properly so they patched it over with an error message?
This is what I would like to know, too, but you phrased it way better than I did.
Ok 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.
I 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.
> Meanwhile the compiler still can't compile many even mildly complex SwiftUI views and expressions with the "The compiler is unable to type-check this expression in reasonable time" error.
That seems like a bug in language design? What's the story behind that? Did they inadvertently make something that was quadratic or worse and then realized it was too late or too fundamental to fix it properly so they patched it over with an error message?