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.
This is what I would like to know, too, but you phrased it way better than I did.
> A different approach to type checking is required to fix it.
I agree, are they actively working on this though?
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.
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.
> 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?