5 ms·

> You quickly start getting compile errors if your method bodies are deemed too complex ("The compiler is unable to type-check this expression in reasonable tim

• lilyball 4y ago
  The problem is calculating all the types. This is largely a consequence of overloading (and especially operator overloads) and literals. Splitting them up into separate variables works because Swift type-checks each line separately, so moving an expression into a separate variable makes Swift resolve the type for that expression on its own instead of as part of a larger expression. For example, if you have the line print(1 + (2 as UInt)) this compiles as it infers the type of `1` to be UInt as well. But if you split it up let a = 1 let b = 2 as UInt print(a + b) you get a type error as you cannot add Int + UInt. This demonstrates how the declaration `let a = 1` forces it to resolve the type there, and the default type for integral literals is Int.
  • saghm 4y ago
    Oh, that's disappointing. I had assumed that Swift did "full" type inference by backtracking from usage to assignment and then checking to see if the value assigned fit the constraints of the usage rather than just checking a single statement at a type like C++'s `auto`. I think I first encountered type inference like this from an OCaml course in college, but at this point I'm most used it it from Rust (for example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=59e0f0049d2b3d0b676ffda2e512ccf8 https://play.rust-lang.org/?version=stable&mode=debug&editio...).
    • lilyball 4y ago
      According to https://github.com/apple/swift/blob/6d2a3bbf9d518c2ff8c637313d1a459f40e5d6bc/docs/TypeChecker.md https://github.com/apple/swift/blob/6d2a3bbf9d518c2ff8c63731... > The Swift language contains a number of features not part of the Hindley-Milner type system, including constrained polymorphic types and function overloading, which complicate the presentation and implementation somewhat. On the other hand, Swift limits the scope of type inference to a single expression or statement, for purely practical reasons: we expect that we can provide better performance and vastly better diagnostics when the problem is limited in scope. However Hindley-Milner systems are generally linear in complexity whereas Swift's type system experiences combinatorial complexity explosions in the presence of overloads and operators and literals.
      • saghm 4y ago
        Yeah, it makes sense that they have features that make it harder. I can't say that it's the _wrong_ choice, but it's enough to remove any potential remaining interest I might have even if it did reach the level of support on Linux that I would otherwise want. I honestly prefer not having function overloading, and I certainly wouldn't want to give up features that I actually would want to use to be able to have it be supported in a language.
  • int_19h 4y ago
    Is it the same fundamental problem as with C# overloading and lambdas? http://web.archive.org/web/20150905081104/http://blogs.msdn.com/b/ericlippert/archive/2007/03/26/lambda-expressions-vs-anonymous-methods-part-four.aspx http://web.archive.org/web/20150905081104/http://blogs.msdn....
• UncleEntity 4y ago
  I’m just wondering how big of an expression it takes so that the compiler can’t do a simple tree walk in a reasonable amount of time?
• sixstringtheory 4y ago
  You can often fix this particular error by removing all type inference. Declare all variable types and include the types of any static properties/functions before the dot operator.
• spfzero 4y ago
  In the cases I've gotten this error, I am guessing it is covering something a bit more complicated in how it needs to discover the cause and generate an error message. I've found actual other errors in the code, removed them, and then this message goes away. It might be that whatever compiler improvements or pre-pass over SwiftUI is not completely working yet.