2017 LLVM Developers’ Meeting: “Implementing Swift Generics ”
2017 LLVM Developers’ Meeting: “Implementing Swift Generics ” on HackerTube: recommended by 2 Hacker News commenters across 2 separate months, 2017–2026.
Swift compiler engineers explain how Swift implements generics using dictionary-passing with reified type metadata. They compare it with Java-style uniform representation and C++ or Rust monomorphization.
What HN commenters said
4 Hacker News comments link this video. Each one links back to its thread.
favoritedOct 2022Recommends
Swift's generics have some unique properties at module boundaries to allow for a stable ABI while enabling library evolution. To get additional background, you might be interested in this[0] conference talk (the paper's author is one of the co-presenters). Also, this post[1] by a Rust and Swift compiler engineer talks about what Swift does differently than other languages, and the tradeoffs that are involved. [0] ▶ this video [1] [link]
in “Compiling Swift Generics [pdf]” · View on HN
VeedracDec 2017Recommends
If you're interested, there's a very nice talk on how Swift's generics compile. It's different to Rust in some key ways. ▶ this video
in “Type Erasure in Swift” · View on HN
mananaysiempreApr 2026Cites it
> It doesn't make sense to me that an embedded VM/interpreter could ever outperform direct code. You're adding a layer of abstraction and indirection, so how is it possible that a more indirect solution can have better performance? It is funny, but (like I’ve already mentioned[1] a few months ago) for serialization(-adjacent) formats in particular the preferential position of bytecode interpreters has been rediscovered again and again. The earliest example I know about is Microsoft’s MIDL, which started off generating C code for NDR un/marshalling but very soon (ca. 1995) switched to bytecode programs (which Microsoft for some reason called “format strings”; these days there’s also typelib marshalling and WinRT metadata-driven marshalling, the latter completely undocumented, but both data-driven). Bellard’s nonfree ffasn1 also (seemingly) uses bytecode, unlike the main FOSS implementations of ASN.1. Protocol Buffers started off with codegen (burying Google user in de/serialization code) but UPB uses “table-driven”, i.e. bytecode, parsing[2]. The most interesting chapter in this long history is in my opinion Swift’s bytecode-based value witnesses[3,4]. Swift (uniquely) has support for ABI compatibility with polymorphic value types, so e.g. you can have a field in the middle of your struct whose size and alignment only become known at dynamic linking time. It does this in pretty much the way you expect[5]: each type has a vtable (“value witness”) full of compiler-generated meth
in “A tail-call interpreter in (nightly) Rust” · View on HN
favoritedNov 2022Cites it
The Swift story around ABI stability and library evolution is pretty unique. Relatedly, its approach to generics doesn't fall into either of the 2 traditional paths (either box everything like Java and C#, or template instantiation like C++ or Rust). [link] ▶ this video
in “Swift Project in 2023” · View on HN