KeyPaths, Tuples and Swift 5

Joe_Groff · November 30, 2018, 11:37pm

I think this would be a great starter project. The runtime ABI for keypaths should not need any modification to handle tuple components, so there's no rush to implement this. There's an ABI document that describes the layout of key path objects; the details are somewhat out of date, but the high level structure is the same:

github.com

apple/swift/blob/main/docs/ABI/KeyPaths.md

# Key Path Memory Layout

**Key path objects** are laid out at runtime as a heap object with a
variable-sized payload containing a sequence of encoded components describing
how the key path traverses a value. When the compiler sees a key path literal,
it generates a **key path pattern** that can be efficiently interpreted by
the runtime to instantiate a key path object when needed. This document
describes the layout of both. The key path pattern layout is designed in such a
way that it can be transformed in-place into a key path object with a one-time
initialization in the common case where the entire path is fully specialized
and crosses no resilience boundaries.

## ABI Concerns For Key Paths

For completeness, this document describes the layout of both key path objects
and patterns; note however that the instantiated runtime layout of key path
objects is an implementation detail of the Swift runtime, and *only key path
patterns* are strictly ABI, since they are emitted by the compiler. The
runtime has the freedom to change the runtime layout of key path objects, but
will have to maintain the ability to instantiate from key path patterns emitted

This file has been truncated. show original

A tuple component ought to be compiled to the same runtime representation as a "struct stored property" component, with the in-memory offset of the tuple element from the start of the tuple stored instead of a struct field. The main thing missing is a representation for the tuple component in the AST (KeyPathExpr::Component) and SIL (KeyPathPatternComponent) data structures. If you add "tuple element" cases to both of those enums, teach the type checker to recognize references to tuple elements and create a tuple component in the AST, teach SIL generation to map that to the SIL component representation, and finally teach LLVM IR generation to emit a struct key path component into the binary, then you should be good to go.