2017 LLVM Developers’ Meeting: “Implementing Swift Generics ”

> 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

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

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

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