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&editio...).
> 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.
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.
