[foobazgt]

No joke, that's just wild. I'd expect an expression like that to type-check literally a million times faster - at the least. Even after reading the article, it's not clear why that particular expression is so egregiously poor.

[recursivecaveat]

From the post they link to:

> The Swift standard library has 17 overloads of + and 9 types adopting the ExpressibleByStringLiteral Protocol. This leads to an exponential combination of types and operators for the constraint solver to try.

I think the ExpressibleBy thing means that a string literal can be interpreted to mean any of those 9 types. Personally I agree with you; I would actually suggest that the compiler error out if there are anywhere near this many interpretations of an expression. Apparently the corrected expression compiles in 0.19s, which is unacceptable to me. I would much rather pay the cost once of adding a few type annotations or intermediate expressions than pay that fifth of a second over and over and over again for every recompile of that file. Since the types a pretty global constraint system, the expression is a landmine as well: you could fiddle with some distant overload which causes it to attempt the permutations in a different order and suddenly start timing out again.

[MangoToupe]

I would rather just have a flag to require type annotations to simply not have to worry about this. I find code much harder to read without them anyway.

[alain_gilbert]

> Even after reading the article, it's not clear why that particular expression is so egregiously poor.

I'm glad I'm not the only one wondering why this is not instant to type check.

[saagarjha]

Plus is heavily overloaded