amos> the compiler is unable to type-check this expression in reasonable time
good: clear, honest communication
bad: that means the language design is a bit fucked, right? I shouldn't be seeing this several times a day.
butternut@fasterthanlime it’s pretty fucked at the moment, but this issue is actively being worked on
Matthew Martin@fasterthanlime I.... write.... python....we....have...learned...to....be...patient...
Edvin Malinovskis@fasterthanlime what defines the reasonableness of time? 👀
Pierre Lebeaupin@nCrazed @fasterthanlime 1,000,000 disjunctions or 512MB (!) of working space for just that expression, whichever comes first. Believe it or not, it used to be wall clock time at some point: https://forums.swift.org/t/roadmap-for-improving-the-type-checker/82952
Roadmap for improving the type checker
Roadmap for improving the type checker In the past, we've released various "manifestos" and "roadmaps" to discuss planned improvements to the language. This post is also a roadmap of sorts, but instead, the focus is on the implementation rather than user-visible language changes (however, I will briefly mention a few potential language changes at the very end). Specifically, I'm going to talk about some work we are doing to improve expression type checking in the Swift compiler. This includes c...
OneSadCookie@fasterthanlime ad-hoc overloading was a mistake
@fasterthanlime That part of Swift is definitely effed up. And it’s hard to predict, so there’s no advice for avoiding it, just “break up your expressions into multiple statements when you inevitably end up stumbling on it”.
PointlessOne 
@fasterthanlime a Turing-complete type system would do that you your compiler.
cassie@fasterthanlime overloading + thorough type inference together means NP complete problems
the esoteric programmer@fasterthanlime sorry, what? this is probably the rust, or swift I suppose, version of I'm in absolute hell