The Swift compiler is slow due to how types are inferred
The Swift compiler is slow due to how types are inferred
How a 10 year old design choice for Swift’s type checker still haunts us to this day
A notable case study for anyone designing a type system for their own language.
Swift's compiler can infer ambiguous expressions like enum case names based on their type, inferred from surrounding context. This makes the syntax less verbose, but at a cost; some seemingly benign expressions take several seconds to type-check, after which the compiler ultimately gives up with an unhelpful error message: "the compiler is unable to type-check this expression in reasonable time".
The linked post goes into more detail.
I've been learning Swift recently, and I have a really ambiguous feelings about it as a language. It has many things I like, but it also feels like the dictionary definition of "designed by committee" with a billion features bolted on to it, with often multiple different ways of expressing the same thing (quick, how many syntaxes are there for closures?), and it feels like it's overly complex because it has too many abstractions for doing approximately the same thing but not quite. Like concurrency and memory safety for example, where you have
asyncand actors and tasks, the new isolation region stuff, the concurrent memory access rules that apply even outside of async contexts, borrow / consume etc. etc. and all of which interact in sometimes frankly fairly confusing and not too well documented ways.Especially the concurrency and memory safety side could use some sort of overarching abstraction instead of a dozen different ones that get bolted on one at a time on top of each other as problems are discovered with the earlier ones. While eg. Pony isn't a simple language as such, at least for me its reference capabilities + actors are much easier to reason with than Swift's
async+ actors + tasks + isolation regions + memory access conflict rules + borrow / consume + kitchen sink setup