Mastodawn

orwell famously said that freedom is the freedom to say `2 + 2 == 4`. on the swift project, our crack type-checker team is working hard to give our developers that freedom, in reasonable time 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...

Swift Forums

Show thread

Jon889 Oct 31

@joe this is great to hear, even if I don’t fully understand it. I’m curious though why Kotlin doesn’t seem to have this issue but seems quite similar to Swift?

Show thread

cassie Nov 4

@Jon889 @joe one cause of much trouble in Swift is that operators are largely treated as free functions, which means you have lots of overloads to resolve, whereas in Kotlin they seem to be bound as a method of the LHS. From reading the description of the type inference there it also sounds like it might commit more and have less backtracking? Unsure.

Show thread

cassie

@Jon889 @joe Another cause of trouble in Swift that’s mentioned in the post is that the number 1 could be either an Int or a Double so you have to check a lot more overloads if there are multiple numeric literals in an expression, whereas Kotlin requires you to have a decimal point in floating point types.