Lol this sounds funny, any other compilers that do this? Why does this happen exactly?
> It does not even tell you what part of code it is having issues with so you could change it. You have to comment/uncomment blocks of code to find the problematic part.
Awful.
TypeScript has a notorious "Type instantiation is excessively deep and possibly infinite" warning that can often be unsafely ignored with a `@ts-expect-error` comment
My question stands: why does this happen and how come it is still so primitive that you do not even get to know the location of the issue?
let result: Double = -(1 + 1) + -(1 + 1) - 1
Wild. :P
WITH THE EXCEPTION OF SWIFTUI, which relies entirely on inferring highly nested generic types, and stands out as a uniquely problematic Swift framework for that and other reasons. I don't use SwiftUI.
Using Xcode taught me to keep my expectations low for my programming environment. The compiler would straight up crash with shocking regularity. The debugger was utterly useless a huge majority of the time (it would just lose track of symbols and couldn’t inspect anything when you hit a breakpoint, every expression you would type to lldb would fail with an inscrutable error.) I had to keep a script around to blow away all of Xcode’s DerivedData and restart it, and I probably used it a half dozen times a day. It was terrible.
With Rust I’m using RustRover, which IIUC uses rust-analyzer which is part of the vanilla toolchain (ie. vim/neovim or vscode will be just as good as they can use it too), and I’m continually shocked at how well it works. I’ll be typing an expression that has an ambiguous type, and the moment I finish it with something unambiguous, the editor responds by filling in all the types around it within a second. And this is with tons of map/filter/iter expressions where the type inference is insanely complex. There’s no restarting the IDE because it’s out to lunch. There’s no expression that rust-analyzer can’t figure out but the compiler can (unlike swift which seems to have one type checker for editing and a different type checker in swiftc and they disagree constantly.) It’s fast, it’s reliable, and most importantly it’s correct.
Trust me, if you think Swift’s tooling issues are unavoidable reality, you need to see how good other languages have it.
Swift's compile time performance is obviously well documented. It's not great, and performance is definitely one of the trade-offs. SwiftUI leans heavily on the compiler and is very much at the sharp end of this. Most "normal Swift" code is by and large just fine. Of course discussions tend to spiral outwards, but stripping context and adding largely uninformed, quick judgements rarely adds value to any discussion.
The link kind of explains why this was a difficult problem, but I think it's worth a moment to consider why this particular difficult problem just wasn't solved. Why was Apple OK with just shrugging, eh, it's hard ?
This is a Quality of Implementation issue. Quality is truly important but because Quality is hard to turn into a metric you'll see management don't like to make it a goal, after all they can't really measure if they succeeded and so when it is competing with other things which are goals it's just abandoned.