Yeah. My understanding is the design of type inference is flawed and requires exponential complexity to resolve and it’s not fixable without breaking change.
Why this is not a top priority before literally anything else?
Yeah. I have a bunch of code with bog-standard linear algebra classes (vec2, vec3, mat2, ...). No generics, no nothing. Just simple classes with operator overloading.
After the recent minor XCode upgrade, Swift can't deduce the type for an expression `((v2 * scalar1) * v3)`, I have to split `let tmp1=v2*scalar1` for it to work.
As a user, I couldn’t care less about the algorithmic beauty of the type system if it works, lets me type complex things reliably, and is fast enough to stay out of my way. Does it do that by being a mess of duct table and plywood? Totally fine for me.
And yet TypeScript doesn't fail with a cryptic nonsensical error just because you have the impossible component with an unfathomable number of two nested lists, like in SwiftUI.
No, I'm saying it has a worse system than Swift's. The point I'm making is that they've designed things such that the normal case doesn't hit this, while Swift keeps adding APIs that exercise the worst of their type system.
Isn't this literally what the person above is talking about?
> Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc).
The issue is that this is a big, known, common problem that cannot be solved, apparently