What does it mean to “use” subtyping vs typeclasses? Swift protocols are essentially typeclasses with associated types, just like Rust traits.

The Factor build farm, the website, and the concatenative wiki are all built in Factor, if that counts.

FWIW, Windows running on a 64-bit host no longer runs 16-bit binaries.

My original reply was just to point out that constraint solving, in the abstract, can be a very effective and elegant approach to these problems. There’s always a tradeoff, and it all depends on the combination of other features that go along with it. For example, without bidirectional inference, certain patterns involving closures become more awkward to express. You can have that, without overloading, and it doesn’t lead to intractability.

That’s really only true if you have overloading though! Without overloading there are no disjunction choices to attempt, and if you also have principal typing it makes the problem of figuring out diagnostics easier, because each expression has a unique most general type in isolation (so your old CSDiag design would actually work in such a language ;-) )

But perhaps a language where you have to rely on generics for everything instead of just overloading a function to take either an Int or a String is a bridge too far for mainstream programmers.

These days though the type checker is not where compile time is mostly spent in Swift; usually it’s the various SIL and LLVM optimization passes. While the front end could take care to generate less redundant IR upfront, this seems like a generally unavoidable issue with “zero cost abstraction” languages, where the obvious implementation strategy is to spit out a ton of IR, inline everything, and then reduce it to nothing by transforming the IR.

> Still fails on a very recent version of Swift, Swift 6.1.2, if my test works.

FWIW, the situation with this expression (and others like it) has improved recently:

- 6.1 fails to type check in ~4 seconds

- 6.2 fails to type check in ~2 seconds (still bad obviously, but it's doing the same amount of work in less time)

- latest main successfully type checks in 7ms. That's still a bit too slow though, IMO. (edit: it's just first-time deserialization overhead; if you duplicate the expression multiple times, subsequent instances type check in <1ms).

In Swift 6 this is only true if the value’s type is Sendable.

Nah. Slow type checking in Swift is primarily caused by the fact that functions and operators can be overloaded on type.

Separately-compiled generics don't introduce any algorithmic complexity and are actually good for compile time, because you don't have to re-type check every template expansion more than once.

You mean 6 years ago? https://www.swift.org/blog/swift-5-released/

Citation needed on the performance loss. So far only a handful of SIL optimizer passes have been rewritten in Swift.